前言
在上一文里我們通過一個例子回顧了OAuth 2.0的流程，同時指出了OAuth 2.0的局限性：客戶端無法認定資源擁有者就是正確的擁護者，雖然市面上的OAuth 2.0能夠保證授權的安全性，但是OAuth 2.0本身并沒有對用戶認證提供明確的規范。這就是OIDC產生的契機。
OIDC
OIDC是OAuth 2.0的一個變種。
OIDC(OpenID Connect)建立在Auth 2.0的流程之上，提出了終端用戶認證標識ID Token概念。符合OIDC流程的一定符合OAuth2.0。OAuth 2.0 是關于如何發布訪問令牌(AccessToken)的規范;而OIDC是關于如何發布ID 令牌的規范。雖然這兩種令牌都是以JWT的形式體現。
在RFC 6749中定義的一個OAuth2.0授權端點(authorization endpoint) 用以請求授權，該端點需要一個response_type的參數用來通知授權服務器所需的授權類型，通常包括了code和token兩種。OIDC擴展了這一屬性，增加了id_token和none。那么response_type的值現在可能有下列組合的情況：
- code
- token
- id_token
- code token
- id_token token
- code id_token
- code id_token token
- none
另外如果該請求是一個OIDC授權認證請求還必須包含一個值為openid 的scope參數，這是區分普通OAuth 2.0和OIDC的關鍵。
OIDC的關鍵術語
OIDC規定了一些術語用來提高我們學習的門檻:
- EU：End User 終端用戶
- RP：Relying Party 即客戶端(client)，授權和認證的最終消費方，我搞不懂為啥要玩多余的概念
- OP：OpenID Provider，對EU進行認證的服務提供者
- ID Token：JWT格式，EU的認證通過后生成憑證，供RP消費
- UserInfo Endpoint：通過憑據查詢用戶基本信息的接口，建議上HTTPS。
OIDC的流程
OIDC復用了OAuth2.0的授權流程，在授權的過程中增加了一些“小動作”來進行用戶認證。結合其術語，大致的流程是這樣的：
RP發送一個認證請求給OP;
OP先對EU進行身份認證，確認無誤后提供授權;
OP把ID Token和Access Token(需要的話)返回給RP;
RP使用Access Token發送一個請求UserInfo EndPoint;(可選)
UserInfo EndPoint返回EU的Claims。(基于第4個步驟可選)
OIDC協議流程圖
另外，OIDC歸納了三種復用OAuth 2.0的流程：
- Authorization Code Flow：使用OAuth2的Authorization Code模式來換取Id Token和Access Token。
- Implicit Flow：使用OAuth2的Implicit模式獲取Id Token和Access Token。
- Hybrid Flow：以上兩種的混合實現。
總結
協議這個東西學起來確實比較枯燥難懂，需要結合一些場景才能說清楚，說實話有些東西我也云里霧里，不過這個是無法跳過去的東西。先不要想太多為什么，后續會結合一些場景來搞明白上面的術語和流程。
原文鏈接：https://mp.weixin.qq.com/s/wPik1Tf2IwC08KkVFvd6Og
