OAuth 幫助 Client 解決了 authorization 的問題，也就是當使用者 (Resource Owener) 想要透過 Client 取得資源的時候，透過 Authorization server 和 OAuth 流程來授權 Client 取的資源。

但是 OAuth 流程並無法協助 Client 同步解決 authentication 的問題。當使用者最初想要使用 Client 的時候，還是必須在 Client 端先登入、驗證身份。如果能夠也讓 Resource Server 來幫忙解決 authentication 的問題是不是就更好了呢？也就是說，Client 直接將 authentication 和 authorization 委託給第三方處理。

OpenID

今天所談到的 OpenID 是第三代的 OpenID 協定，全名是 The OpenID Connect Protocol，簡稱 OIDC。不過這裡當我們談到 OpenID 的時候，就是指 OIDC。

OpenID 的實作是架構在 OAuth 2.0 之上，讓 Authorization server 提供 authentication 的功能。

Roles

同樣的這裡先來介紹 OpenID 當中的角色

1. End User

使用者，也就是準備要登入使用 Client 的使用者

2. OpenID Provider (OP)

提供使用者身份驗證功能的 server。在 OAuth 的架構下，它基本上就是 Authorization server 並且有同樣的功能。

3. Relying Party (RP)

依賴 OpenID Provider 提供使用者驗證功能的一方，在 OAuth 架構下，它就會是我們先前談到的 Client。

Client Type

OpenID 的 Client Type 和 OAuth 的相同，分別有

• 1. confidential client - 擁有受保護的 server 可以存放重要的 secret
• 2. public client - 譬如 SPA 或是 native app，無法安全存放重要的 secret

Flows

最後，OpenID 定義了三種驗證流程，分別是

• OIDC Authorization Code Flow
• OIDC Implicit Flow
• OIDC Hybrid Flow

看到前兩個流程的名字是不是覺得似曾相識呢？沒錯，他其實就建構在 OAuth 流程之上。

明天讓我們來繼續看更多關於 OpenID 的內容吧！