用OAuth 2.0和OIDC實(shí)現(xiàn)用戶身份認(rèn)證與授權(quán)

作者：陳峻 2021-09-17 09:00:00

本文將和您探討用于用戶身份驗(yàn)證和授權(quán)的OAuth 2.0，以及基于OIDC的隱式與授權(quán)代碼流程的相關(guān)基礎(chǔ)知識(shí)。

【51CTO.com快譯】目前，OAuth 2.0已是“委托授權(quán)(delegated authorization)”的一種行業(yè)標(biāo)準(zhǔn)。它能夠?yàn)閼?yīng)用程序或客戶端提供，針對(duì)其他應(yīng)用服務(wù)的相關(guān)數(shù)據(jù)與功能的訪問權(quán)限。當(dāng)然，OAuth 2.0側(cè)重于授權(quán)，而并非關(guān)于身份驗(yàn)證的規(guī)定。而OpenID Connect(OIDC)則在OAuth 2.0之上添加了一個(gè)基于標(biāo)準(zhǔn)的身份驗(yàn)證層。也就是說(shuō)，作為身份驗(yàn)證框架，OIDC建立在OAuth 2.0之上。

在本文中，我們將介紹OAuth 2.0和OIDC在用于身份驗(yàn)證和授權(quán)方面的基礎(chǔ)知識(shí)，并在其中涉及到兩種常見的流程，即：隱式流程(Implicit Flow)和授權(quán)代碼流程(Authorization Code Flow)。

OAuth 2.0入門

如前所述，OAuth 2.0是委托授權(quán)的行業(yè)標(biāo)準(zhǔn)。目前市場(chǎng)上有許多OAuth的提供商，以及典型的使用場(chǎng)景。例如，“使用Facebook登錄”按鈕，就是通過采用OAuth 2.0，實(shí)現(xiàn)了對(duì)于各種網(wǎng)絡(luò)和移動(dòng)應(yīng)用的支持。下面，我們將對(duì)此進(jìn)行深入的討論。

先決條件

首先，應(yīng)用程序和客戶端都必須完成這授權(quán)服務(wù)器上的注冊(cè)。而在注冊(cè)的過程中，aclient_id和client_secret會(huì)相繼生成，并被配置到請(qǐng)求身份驗(yàn)證的應(yīng)用和客戶端上。

1. 當(dāng)用戶(在OAuth 2.0中也稱為“資源所有者”)點(diǎn)擊應(yīng)用上的“使用Facebook登錄”按鈕時(shí)，應(yīng)用程序會(huì)向授權(quán)服務(wù)器的登錄URL，發(fā)送授權(quán)請(qǐng)求。通常，F(xiàn)acebook之類的授權(quán)請(qǐng)求會(huì)包括許多參數(shù)。為簡(jiǎn)潔起見，我們省去RFC6749規(guī)定的完整參數(shù)列表，僅包含如下參數(shù)：

client_id—為授權(quán)服務(wù)器排他地標(biāo)識(shí)了應(yīng)用程序。
response_type--表明客戶端所需的授權(quán)代碼。
redirect_uri--指定授權(quán)服務(wù)器將通過重定向進(jìn)行后續(xù)身份驗(yàn)證的URL。

2. Facebook的授權(quán)服務(wù)器會(huì)提示用戶輸入他們的用戶名和密碼，并以可選的方式要求回答驗(yàn)證所需的安全問題。

3. 一旦通過身份驗(yàn)證，用戶可能會(huì)看到一張“資源同意表”，其中列出了應(yīng)用程序想要訪問到的Facebook資源集(例如，用戶的公開個(gè)人資料等)。

這些已同意的資源集是通過對(duì)初始授權(quán)請(qǐng)求中的scope參數(shù)所指定的。

4. 一旦用戶被授權(quán)訪問其請(qǐng)求的資源，用戶將會(huì)被重定向回帶有授權(quán)代碼的應(yīng)用程序。

其中，授權(quán)服務(wù)器對(duì)于用戶進(jìn)行重定向的URL，是通過redirect_uri參數(shù)指定的，該參數(shù)也被包含在最初的授權(quán)請(qǐng)求中。

5. 然后，應(yīng)用程序會(huì)與客戶端及授權(quán)服務(wù)器交換授權(quán)代碼，并獲取opaque訪問令牌(或刷新令牌)，并將client_id和client_secret作為請(qǐng)求的一部分進(jìn)行傳遞。

6. 最后，應(yīng)用程序可以使用訪問令牌，去訪問Facebook上所請(qǐng)求的資源。

什么是OpenID Connect(OIDC)?

如您所見，OAuth 2.0的主要目的是為了委托授權(quán)。換句話說(shuō)，OAuth 2.0可以授予某個(gè)應(yīng)用程序訪問另一個(gè)應(yīng)用程序所擁有的數(shù)據(jù)權(quán)限。而由于它并不關(guān)注身份驗(yàn)證，因此，任何使用OAuth 2.0的身份驗(yàn)證實(shí)現(xiàn)都是非標(biāo)準(zhǔn)的。這也就是OpenID Connect(OIDC)的用武之地。OIDC是在OAuth 2.0之上添加了一個(gè)基于標(biāo)準(zhǔn)的身份驗(yàn)證層。

OAuth 2.0流程中的授權(quán)服務(wù)器，在OIDC中承擔(dān)的是身份服務(wù)器(或提供者)的角色。其實(shí)，OIDC的底層協(xié)議幾乎與OAuth 2.0相同，只是身份服務(wù)器向被請(qǐng)求的應(yīng)用程序提供的是身份令牌(如，ID令牌)罷了。此處的身份令牌是對(duì)有關(guān)用戶身份驗(yàn)證的聲明，以及編碼的標(biāo)準(zhǔn)方式。

下面，我將描述兩種流行的OIDC流程：隱式流程和授權(quán)代碼流程。

先決條件

對(duì)于這兩個(gè)流程，應(yīng)用程序和客戶端同樣必須完成這授權(quán)服務(wù)器上的注冊(cè)。而在注冊(cè)的過程中，aclient_id和client_secret同樣會(huì)相繼生成，并被配置到請(qǐng)求身份驗(yàn)證的應(yīng)用和客戶端上。

OIDC隱式流程

OIDC隱式流程是兩者中較簡(jiǎn)單的一種。您可以使用帶有同步網(wǎng)關(guān)(Sync Gateway)的 Couchbase Lite客戶端，進(jìn)行身份驗(yàn)證。讓我們沿用上面的例子，討論其具體流程。

同樣，在用戶點(diǎn)擊了應(yīng)用程序上的“使用Facebook登錄”按鈕時(shí)，認(rèn)證請(qǐng)求比上述OAuth多了一個(gè)遵從OIDC有關(guān)規(guī)范的典型參數(shù)：scope。它包含了openid的范圍值。

接著，我們將上述OAuth部分的第2步換成身份服務(wù)器。而在第4步中，用戶將會(huì)攜帶著身份令牌、或可選的訪問令牌，被重定向回應(yīng)用程序。而身份驗(yàn)證服務(wù)器也會(huì)根據(jù)redirect_uri的參數(shù)值，去指定URL。

在省去了上例的第5步后，應(yīng)用程序會(huì)根據(jù)OIDC的標(biāo)準(zhǔn)規(guī)范，去驗(yàn)證身份令牌，并檢索已存儲(chǔ)的、經(jīng)過身份驗(yàn)證的用戶身份。

OIDC授權(quán)代碼流程

OIDC的授權(quán)代碼流程與之前描述過的OAuth 2.0的授權(quán)代碼流程，也非常相似。下圖再次展示了Facebook登錄的流程：

OIDC授權(quán)代碼流程的前4步，與隱式流程相同。不過，它沿用了OAuth的第5步。最后，應(yīng)用程序會(huì)根據(jù)OIDC的標(biāo)準(zhǔn)規(guī)范去驗(yàn)證身份令牌，并檢索已存儲(chǔ)的、經(jīng)過身份驗(yàn)證的用戶身份。

JSON Web Token(JWT)

OIDC的一個(gè)關(guān)鍵元素是安全身份令牌。它通過被稱為JSON Web Token(JWT)的標(biāo)準(zhǔn)格式，對(duì)有關(guān)用戶的身份驗(yàn)證聲明(authentication claims)進(jìn)行編碼。此處的“聲明”可以被理解為關(guān)于用戶的斷言。而JWT往往是經(jīng)由數(shù)字簽名的。如下代碼段便是帶有一組典型聲明的JWT示例：

JSON 
{ 
  "sub": "AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4", 
  "name": "Priya Rajagopal", 
  "email": "priya.rajagopal@example.com", 
  "iss": "https://pk-demo.okta.com/OAuth 2.0/default", 
  "aud": "WuRuBAgABMP7_w4K9L-40Jhh", 
  "iat": 1622246311, 
  "exp": 1624838311, 
  "amr": [ 
    "pwd" 
  ] 
}