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