和 OIDC Authorization Code Flow 相比，OIDC Implicit Flow 少了 authorization code 的這個步驟

Roles

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

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

Steps

1

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

2

這時 Client 就會將使用者轉 (redirect) 到 OpenID Provider

3

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

4

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

5

當 OpenID Provider 確認使用者後，便會將使用找導回 (redirect) 到 Client，並同時在 URL 當中直接挾帶 ID token。之後，Client 就可以透過這個 ID token 來識別使用者。

OAuth Implicit grant 不是推薦的實作方式，因為 access token 會暴露在 URL 當中，一旦這個 access token 被他人截獲，他人就可以用這個 access token 來取得更多資源。

然而 OIDC Implicit Flow 的風險相對較小。ID token 本身所攜帶的個人資訊相對有限，即便被他人截獲，他人也無法利用這個 ID token 來向 Resource server 取得更多資源。

明天讓我們一起來看看最後一種 OIDC 的流程吧！