OpenID Connect

OpenID Connect 為 OpenID Foundation (OIDF)所規範的一種以使用者為中心 (User Centric)及 OAuth 2.0 為基礎之身分驗證與權限授權的開放標準，提供友善 的 APIs 給客戶端(Client)來介接，讓客戶端藉由 OpenID Connect 機制來完成對使 用者(End-User)的身分驗證，以及透過 OAuth 2.0 標準取得使用者相關資源存取 權限的授權。

此外，OpenID Connect 也實現了單一登入的機制，對使用者而言，其只需擁 有一組 OpenID 的帳號密碼且經過驗證後，即可在任何支援 OpenID Connect 的網

站直接登入，並使用其服務。解決了以往使用者需分別記取不同網站的帳號密碼，

以及存取不同網站時，需一再輸入帳號密碼的問題。

以下將分別介紹 OpenID Connect 流程中所涉及的主要的角色，以及五種基 本元件之功能說明：

( 2 ). 主要角色

(1). 使用者 (End User)

又稱作 OAuth 2.0 Resource Owner，為存取網站或應用程式的使用者。

(2). 依賴方 (Relying Party ; RP)

又稱作 OAuth 2.0 Client，為提供服務的網站或應用程式等，其透過 OP 端來對使用者進行身分驗證，並取得使用者於 OP 端上的資源存取權或使用 者相關資訊等。

(3). OpenID 身分提供者 (OpenID Provider ; OP)

又稱作 OAuth 2.0 Authorization Server，為提供使用者註冊身分識別帳號，

以及提供 RP 端身分驗證與授權服務(如: 在使用者同意之下，授予 RP 端存 取使用者相關資源的權限)。

( 3 ). Authorization Code Flow

說 明 OpenID Connect 運 作 的 流 程 ， 以 OAuth 2.0 (RFC6749) 規 範 之 Authorization Code Flow 為例: (圖九)

圖 九：OpenID Connect - Authorization Code Flow (OpenID Foundation 官網) 以下將依序介紹圖中各步驟之說明:

A. Client 向 Authorization Server 提出驗證請求，並把 Resource Owner 的 User-Agent 導向 Authorization Endpoint 進行驗證。其中驗證請求將傳送 相關的參數(如: Client ID、Redirection URI、Scopes 等)。

B. Authorization Server 透過 User-Agent 來驗證 Resource Owner，並詢問 Resource Owner 是否授予 Client 相關資源存取權，即 Client 資源的宣告 (Scopes)，或者是駁回 Client 的存取申請。

C. 若 Resource Owner 同意授權後，Authorization Server 會把 User-Agent 導回先前指定的 Redirection URI，並夾帶 Authorization Code。

D. Client 向 Authorization Server 的 Token Endpoint 提出授權 Token 請求。

其中授權 Token 請求將傳送相關的參數(如: Client ID、Client Secret、

Redirection URI、Authorization Code 等)

E. Authorization Server 驗證 Client 之 Credentials(Client ID、Client Secret)，

以及 Authorization Code，並回傳授權 Token(Access Token)與可選的 Refresh Token。

而 Access Token 主要用來存取 Authorization Server 所提供的 API，以 Google 為例，當 Client 相關資源的宣告含有 Google Drive 資源時，Client 能以 Access Token 存取 Google Drive Endpoint，來對使用者雲端硬碟進行相關操作。另外，

由於 Access Token 具有時效性，一旦超過時效 Client 便無法進行 API 的呼叫，因 此可藉由 Refresh Token 再向 Authorization Server 重新換取新的 Access Token。

( 4 ). 安全性

以 Authorization Code Flow 為例，由於 Client 不直接向 End User 要求資源存 取許可，而是把 End User 導向 Authorization Server 要求許可，Authorization Server 在透過轉址來告訴 Client 授權許可碼(Authorization Code)，因此在轉址回去前，

Authorization Server 會 先 驗 證 End User 並 取 得 授 權 ， 而 End User 只 向 Authorization Server 進行驗證，所以 Client 絕不會拿到 End User 的帳號與密碼，

增加了 End User 帳戶的安全性。

此外，當 End User 驗證完後，Authorization Server 並不會立即回傳授權 Token 給 Client，由於在返回的過程中皆會經過 User-Agent，為了避免惡意程式非法偷 竊 User-Agent 上的資訊，因此改以 Authorization Code 的方式讓 Client 再次向 Authorization Server 來換取授權 Token，更提高了安全性。

3.3 Keystone