【】目前，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": "[email protected]",
- "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
【IDC.NET译稿，合作站点转载请注明原文译者和出处为IDC.NET.com】
文章来源网络，作者：管理，如若转载，请注明出处：https://shuyeidc.com/wp/134829.html<
