今天來看最後一種流程，OIDC Hybrid Flow。

OIDC Hybrid Flow 包含了 OIDC Authorization Code Flow 以及 OIDC Implict Flow 的內容，是設計給「前後分離」的 Client 使用，差別在於在 OIDC Authorization Code Flow 當中， OpenID Provider 將 access token, refresh toke, ID token 送到 Client 的後端，之後 Client 可以根據 ID token 的內容決定要 render 什麼樣的前端畫面。

而在 OIDC Hybrid Flow 當中，OpenID Provider 同樣將 access token, refresh toke 送到 Client 的後端，但是，會把 ID token 送到 Client 前端，讓前端的 SPA 根據 ID token 決定自己要 render 什麼畫面。

Roles

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

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

Steps

1

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

2

這時 Client 前端就會將使用者轉 (redirect) 到 OpenID Provider。跟 OIDC Authorization Code Flow 不同的是，這裡的請求沒有攜帶 Code challenge 和 Code challenge method。

3

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

4

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

5

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

6

當 Client 前端收到來自 OpenID Provider 的 authorization code 之後， Client 後端再次向 Authorization server 發出請求，並同時挾帶 authorization code。

7

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

8

最後，拿到 access token 和 refresh token 的 Client 後端，如果想要更多的使用者資訊，可以拿著 access token 向 OpenID Provider 提出請求

看完了 OIDC 三種驗證流程，明天讓我們繼續探索 identity management 的其他內容吧！