基於oAuth2的OIDC原理 學習筆記
摘要：
OAuth2
概念
OAuth 2.0 規範定義了一個授權（delegation）協議，OAuth2.0 不是認證協議。
OAuth解決的大部分問題在於Client和被訪問的資源之間的連線上，在使用者不存在的情況下，使用這種委託訪問。
流程
上圖ABCDE這5...
OAuth2
概念
OAuth 2.0 規範定義了一個授權（delegation）協議，OAuth2.0 不是認證協議。
OAuth解決的大部分問題在於Client和被訪問的資源之間的連線上，在使用者不存在的情況下，使用這種委託訪問。
流程
上圖ABCDE這5個步驟，既是完整的獲取訪問令牌的一個過程，其中：
- Client 為第三方應用程式，
- resource owner 為資源所有者
- user-agent 為類似瀏覽器的代理
- authorization server 授權伺服器
- resource server 資源伺服器
流程如下：
- A) Client使用瀏覽器（User-Agent）訪問Authorization server。也就是用瀏覽器訪問一個URL，這個URL是Authorization server提供的，訪問的Client需要提供（客戶端標識client_id，授權範圍scope，本地狀態state和redirect_uri）這些引數。
- B) Authorization server驗證Client在（A）中傳遞的引數資訊，如果無誤則提供一個頁面供Resource owner登陸，登陸成功後選擇Client可以訪問Resource server的哪些資源以及讀寫許可權。
- C) 在（B）無誤後返回一個授權碼（Authorization Code）給Client。
- D) Client拿著（C）中獲得的授權碼（Authorization Code）和（客戶端標識、redirect_uri等資訊）作為引數，請求Authorization server提供的獲取access token。
- E) Authorization server返回access token和可選的refresh token 以及令牌有效時間等資訊給Client。
- F) client拿到access token後就可以去resources server訪問resource owner的資源
OIDC
定義了一種基於OAuth2的使用者身份認證
OIDC的核心在於在OAuth2的授權流程中，一併提供使用者的身份認證資訊（ID Token）給到第三方客戶端，ID Token使用JWT格式來包裝，得益於JWT（JSON Web Token）的自包含性，緊湊性以及防篡改機制，使得ID Token可以安全的傳遞給第三方客戶端程式並且容易被驗證。此外還提供了UserInfo的介面，用於獲取使用者的更完整的資訊
流程
- RP傳送一個認證請求給OP；
- OP對EU進行身份認證，然後提供授權；
- OP把ID Token和Access Token（需要的話）返回給RP；
- RP使用Access Token傳送一個請求UserInfo EndPoint；
- UserInfo EndPoint返回EU的Claims。
術語：
- EU：End User：一個人類使用者。
- RP：Relying Party ,用來代指OAuth2中的受信任的客戶端，身份認證和授權資訊的消費方；
- OP：OpenID Provider，有能力提供EU認證的服務（比如OAuth2中的授權服務），用來為RP提供EU的身份認證資訊；
- ID Token：JWT格式的資料，包含EU身份認證的資訊。
- UserInfo Endpoint：使用者資訊介面（受OAuth2保護），當RP使用Access Token訪問時，返回授權使用者的資訊，此介面必須使用HTTPS
- AuthN & AuthZ： AuthN代表authentication AuthZ 代表authrization
