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