用OAuth 2.0和OIDC實現(xiàn)用戶身份認證與授權(quán)
譯文【51CTO.com快譯】目前，OAuth 2.0已是“委托授權(quán)(delegated authorization)”的一種行業(yè)標準。它能夠為應(yīng)用程序或客戶端提供，針對其他應(yīng)用服務(wù)的相關(guān)數(shù)據(jù)與功能的訪問權(quán)限。當然，OAuth 2.0側(cè)重于授權(quán)，而并非關(guān)于身份驗證的規(guī)定。而OpenID Connect(OIDC)則在OAuth 2.0之上添加了一個基于標準的身份驗證層。也就是說，作為身份驗證框架，OIDC建立在OAuth 2.0之上。
在本文中，我們將介紹OAuth 2.0和OIDC在用于身份驗證和授權(quán)方面的基礎(chǔ)知識，并在其中涉及到兩種常見的流程，即：隱式流程(Implicit Flow)和授權(quán)代碼流程(Authorization Code Flow)。
OAuth 2.0入門
如前所述，OAuth 2.0是委托授權(quán)的行業(yè)標準。目前市場上有許多OAuth的提供商，以及典型的使用場景。例如，“使用Facebook登錄”按鈕，就是通過采用OAuth 2.0，實現(xiàn)了對于各種網(wǎng)絡(luò)和移動應(yīng)用的支持。下面，我們將對此進行深入的討論。
先決條件
首先，應(yīng)用程序和客戶端都必須完成這授權(quán)服務(wù)器上的注冊。而在注冊的過程中，aclient_id和client_secret會相繼生成，并被配置到請求身份驗證的應(yīng)用和客戶端上。
1. 當用戶(在OAuth 2.0中也稱為“資源所有者”)點擊應(yīng)用上的“使用Facebook登錄”按鈕時，應(yīng)用程序會向授權(quán)服務(wù)器的登錄URL，發(fā)送授權(quán)請求。通常，F(xiàn)acebook之類的授權(quán)請求會包括許多參數(shù)。為簡潔起見，我們省去RFC6749規(guī)定的完整參數(shù)列表，僅包含如下參數(shù)：
- client_id—為授權(quán)服務(wù)器排他地標識了應(yīng)用程序。
- response_type--表明客戶端所需的授權(quán)代碼。
- redirect_uri--指定授權(quán)服務(wù)器將通過重定向進行后續(xù)身份驗證的URL。
2. Facebook的授權(quán)服務(wù)器會提示用戶輸入他們的用戶名和密碼，并以可選的方式要求回答驗證所需的安全問題。
3. 一旦通過身份驗證，用戶可能會看到一張“資源同意表”，其中列出了應(yīng)用程序想要訪問到的Facebook資源集(例如，用戶的公開個人資料等)。
- 這些已同意的資源集是通過對初始授權(quán)請求中的scope參數(shù)所指定的。
4. 一旦用戶被授權(quán)訪問其請求的資源，用戶將會被重定向回帶有授權(quán)代碼的應(yīng)用程序。
- 其中，授權(quán)服務(wù)器對于用戶進行重定向的URL，是通過redirect_uri參數(shù)指定的，該參數(shù)也被包含在最初的授權(quán)請求中。
5. 然后，應(yīng)用程序會與客戶端及授權(quán)服務(wù)器交換授權(quán)代碼，并獲取opaque訪問令牌(或刷新令牌)，并將client_id和client_secret作為請求的一部分進行傳遞。
6. 最后，應(yīng)用程序可以使用訪問令牌，去訪問Facebook上所請求的資源。
什么是OpenID Connect(OIDC)?
如您所見，OAuth 2.0的主要目的是為了委托授權(quán)。換句話說，OAuth 2.0可以授予某個應(yīng)用程序訪問另一個應(yīng)用程序所擁有的數(shù)據(jù)權(quán)限。而由于它并不關(guān)注身份驗證，因此，任何使用OAuth 2.0的身份驗證實現(xiàn)都是非標準的。這也就是OpenID Connect(OIDC)的用武之地。OIDC是在OAuth 2.0之上添加了一個基于標準的身份驗證層。
OAuth 2.0流程中的授權(quán)服務(wù)器，在OIDC中承擔的是身份服務(wù)器(或提供者)的角色。其實，OIDC的底層協(xié)議幾乎與OAuth 2.0相同，只是身份服務(wù)器向被請求的應(yīng)用程序提供的是身份令牌(如，ID令牌)罷了。此處的身份令牌是對有關(guān)用戶身份驗證的聲明，以及編碼的標準方式。
下面，我將描述兩種流行的OIDC流程：隱式流程和授權(quán)代碼流程。
先決條件
對于這兩個流程，應(yīng)用程序和客戶端同樣必須完成這授權(quán)服務(wù)器上的注冊。而在注冊的過程中，aclient_id和client_secret同樣會相繼生成，并被配置到請求身份驗證的應(yīng)用和客戶端上。
OIDC隱式流程
OIDC隱式流程是兩者中較簡單的一種。您可以使用帶有同步網(wǎng)關(guān)(Sync Gateway)的 Couchbase Lite客戶端，進行身份驗證。讓我們沿用上面的例子，討論其具體流程。
同樣，在用戶點擊了應(yīng)用程序上的“使用Facebook登錄”按鈕時，認證請求比上述OAuth多了一個遵從OIDC有關(guān)規(guī)范的典型參數(shù)：scope。它包含了openid的范圍值。
接著，我們將上述OAuth部分的第2步換成身份服務(wù)器。而在第4步中，用戶將會攜帶著身份令牌、或可選的訪問令牌，被重定向回應(yīng)用程序。而身份驗證服務(wù)器也會根據(jù)redirect_uri的參數(shù)值，去指定URL。
在省去了上例的第5步后，應(yīng)用程序會根據(jù)OIDC的標準規(guī)范，去驗證身份令牌，并檢索已存儲的、經(jīng)過身份驗證的用戶身份。
OIDC授權(quán)代碼流程
OIDC的授權(quán)代碼流程與之前描述過的OAuth 2.0的授權(quán)代碼流程，也非常相似。下圖再次展示了Facebook登錄的流程：
OIDC授權(quán)代碼流程的前4步，與隱式流程相同。不過，它沿用了OAuth的第5步。最后，應(yīng)用程序會根據(jù)OIDC的標準規(guī)范去驗證身份令牌，并檢索已存儲的、經(jīng)過身份驗證的用戶身份。
JSON Web Token(JWT)
OIDC的一個關(guān)鍵元素是安全身份令牌。它通過被稱為JSON Web Token(JWT)的標準格式，對有關(guān)用戶的身份驗證聲明(authentication claims)進行編碼。此處的“聲明”可以被理解為關(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"
- ]
- }
其中，
- sub是JWT引用到的用戶。
- iss是JWT的簽發(fā)方。
- aud是令牌授予的對象。
- iat是發(fā)布的時間戳。
- exp是設(shè)定好的過期時間戳。
- amr是用于簽發(fā)令牌的身份驗證方法。
其他資源
- jwt.io對于解碼和驗證某個JWT非常實用，其鏈接為-- https://jwt.io/。
- 由Okta提供的OIDC和OAuth靶場，是一個不錯的資源，您可以在不實際實施的情況下，試用各種流程。
原文標題：OAuth 2.0 and OIDC Fundamentals for Authentication and Authorization，作者：Priya Rajagopal
【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】
