15 - OpenID (3) - OIDC Authorization Code Flow

Step 2

由 Client 將使用者導向 OpenID provider，其 url params 如下

GET /authorize?response_type=code
&client_id=xxx
&state=xxx
&scope=xxx
&nonce=xxx
&redirect_uri=xxx
&resource=xxx
&code_challenge=xxx
&code_challenge_method=xxx

• response_type: 這裡的值為 "code"，代表我們採用 authorization code flow
• client_id: 在 Authorization server 所登記的 Client 的 ID
• state: 當中包含了 Client 當前的狀態資訊，之後會用來比對 OpenID provider response 當中的 state 以確保前後一致
• redirect_uri: 在 step 5 OpenID provider 將使用者導回到 Client 時的 url
• resource: 在 OpenID provider 所登記的 Resource server 的 ID
• code_challenge: PKCE 流程當中的 code challenge
• code_challenge_method: PKCE 流程當中的 code challenge method

基本上大部分內容和先前提到的 OAuth Authorization code grant 幾乎一模一樣，比較不一樣的是 scope 和
nonce

• scope: 代表這個請求所想要取得的使用者資訊，譬如 "openid profile email"
• nonce: 一個隨機值，之後會被放在 ID token 當中回傳給 Client

這裡 state 和 nonce 的功能看起來好像一樣，不過 state 主要是用來防止 CSRF，nonce 則是用來讓 Client 確保 ID token 沒有在溝通過程中沒有被竄改。

Step 5

在使用者輸入帳號密碼，驗證身份完畢之後 (step 3 & 4)，OpenID provider 的回應如下

https://client_redirect_uri/callback?code=xxx&state=xxx

• code: authorization code
• state: 跟上面 request 當中的 state 一樣

Step 6

拿到 authorization code 的 Client，就可以向 OpenID provider 發出 POST 請求

POST /token

grant_type=xxx
client_id=xxx
code_verifier=xxx
redirect_uri=xxx

• grant_type: 這裡會使用 "authorization_code" 代表採用 authorization code flow
• code: 先前 Client 收到的 authorization code
• client_id: 在 OpenID provider 所登記的 Client 的 ID
• code_verifier: PKCE 當中的 code verifier，用來確保當初送出請求和現在送出請求的 Client 是同一個
• redirect_uri: 同先前的 redirect uri

Step 7

收到 Client 發出的 POST 請求，OpenID provider 透過 code 以及 PKCE 確認 Client` 身份之後，就可以發出 response，當中所攜帶的 payload 如下

{
  access_token: xxx,
  token_type: xxx,
  expired_in: xxx,
  refresh_token: xxx,
  id_token: xxx
}

• access_token: Client 可以用來向 Resource server 發送請求
• token_type: token 的類型，譬如 "Bearer"
• expired_in: token 的續存時間
• refresh_token: 在 access_token 到期之後，Client 可以拿 refresh_token 向 OpenID provider 取得新的 access_token
• id_token: 攜帶驗證過後的使用者資訊，讓 Client 能夠知道當前的使用者身份