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