OIDC Authorization Code Flow 和 Authorization Code Grant 幾乎一樣，只差在 ID token 以及有個可以讓我們有機會獲得更多使用者資訊的 endpoint

就讓我們看一下這個似曾相似的流程吧

Roles

在上面這張示意圖中，有幾個主要的 roles:

• User - 使用者
• Browser - 使用者與應用程式的互動介面。這裡遇到的前端介面是 server-side render
• Client - 使用者準備要登入的應用程式
• OpenID Provider - 驗證使用者的應用程式。由於 OpenID 建構在 OAuth 流程之上，因此這個也是先前提到的 Authorization server

Steps

1

使用者來到了應用程式 (Client)，這時候可能想要更多進階的功能，因此點擊了「登入」按鈕

2

這時 Client 就會將使用者轉 (redirect) 到 OpenID Provider，在送出請求的時候，同時挾帶著 Code challenge 和 Code challenge method

3

當 OpenID Provider 收到請求，便會將使用者導向登入頁面。這裡的登入頁面在 OpenID Provider，而不在 Client。

4

使用者看到登入頁面之後，就會輸入自己的帳號密碼，讓 OpenID Provider 進行驗證

5

當 OpenID Provider 確認使用者後，便會將使用者導回 (redirect) 到 Client，並同時在 URL 當中挾帶 authorization code

6

當 Client 收到來自 OpenID Provider 帶有 authorization code 的請求後，緊接著就會再次向 Authorization server 發出請求，並同時挾帶 authorization code 和 code verifier

7

當 OpenID Provider 收到 authorization code 和 code verifier，確認該 Client 的身份之後，就會回傳 access token，refresh token，以及 ID token

8

最後，拿到 ID token 的 Client，就可以從這個 token 當中取得使用者的識別資訊。如果想要更多的使用者資訊，可以拿著 access token 向 OpenID Provider 提出請求

在 OAuth 的 Authorization Code Grant 當中，Client 本身僅能從 Authorization server 獲得取用資源的「授權」，並無法獲得使用者的驗證資訊。這時候 Client 的使用者驗證資訊，來自於自己當初驗證使用者 credentials 的結果

在 OIDC Authorization Code Flow 當中，Client 可以從 OpenID Provider(Authorization server) 獲得取用資源的「授權」，以及使用者驗證的結果（識別資訊）

明天讓我們一起來看看另外一種流程吧！