OAuth 2.0

一、OAuth 2.0

1.1 概述

• 認證授權協定，明确了授權流程
  • 認證
    • Authentication is knowing the identity of the user
  • 授權
    • 指的是resource owner同意client通路其擁有的受保護的資源
    • 與請求處理過程中的Authorization有所差別
      • Authorization is deciding whether a user is allowed to perform an action
• OAuth包含四個角色
  • resource owner
    • An entity capable of granting access to a protected resource
  • resource server

    • The server hosting the protected resources, capable of accepting

      and responding to protected resource requests using access tokens

  • client

    • An application making protected resource requests on behalf of the

      resource owner and with its authorization

  • authorization server

    • The server issuing access tokens to the client after successfully

      authenticating the resource owner and obtaining authorization

    • 寄宿受保護資源和簽發token的伺服器可以是同一個
• 四種角色之間的互動可以用下圖表示

  

  • 其中，A表示詢問resource owner對資源通路的同意，A、B這一過程通常需要以authorization server為中間媒介
  • OAuth定義了Authorization Grant的四種類型
    • authorization code
    • implicit
    • resource owner password credentials
    • client credentials
• refresh token

  

• Protocol Endpoints
  • authorization server endpoints
    • Authorization endpoint
      • used by the client to obtain authorization from the resource owner via user-agent redirection
    • Token endpoint
      • used by the client to exchange an authorization grant for an access token, typically with client authentication
  • client endpoint
    • Redirection endpoint
      • used by the authorization server to return responses containing authorization credentials to the client via the resource owner user-agent
      • 從authorization server切換回client
  • 不是每一個Authorization Grant Type都利用了所有的Protocol Endpoints

1.2 Authorization Code

• 認證授權過程

  

• Authorization
  • Request
    • response_type，client_id，redirect_uri，scope，state
  • Response
    • code，state
• Access Token
  • Request
    • grant_type
    • code
    • redirect_uri
    • client_id
• 适用場景
  • client為server-side，代碼運作在伺服器

1.3 Implicit Flow與PKCE

1.3.1 Implicit Flow

• 認證授權過程

  

• Authorization
  • Request
    • response_type，client_id，redirect_uri，scope，state
  • Response
    • access_token，token_type，expires_in，scope，state
• 适用場景
  • client為client-side，代碼運作在用戶端，一般為javascript腳本

1.3.2 PKCE

• Implicit的缺陷
  • token簽發後會作為重定向的queryString傳回，重定向跳轉時會在曆史記錄裡儲存，浏覽器中的插件等可以讀取
  • 不包括用戶端身份認證
    • 雖然某些情況下可以通過重定向URI确認用戶端身份，但安全性降低
• PKCE是對Authorization Code的拓展，在client-side實作
• PKCE認證授權過程

  

• PKCE的特點
  • 與Implicit類似，代碼運作在client-side，一般為浏覽器
  • 與Implicit的token會儲存在曆史記錄中相比，PKCE隻有Authorization Code會儲存在曆史記錄裡
    • Authorization Code即使被劫持，随機生成的code_verifier可以幫助校驗Authorization Code是否有效
    • code_verifier儲存在client記憶體中

1.4 Password Grant

• 認證授權過程

  

• Access Token
  • Request
    • grant_type，username，password，scope
• 适用場景
  • client與resource server是屬于同一系統内部

1.5 Client Credentials

• 認證授權過程

  

• 适用場景
  • client為resource owner