用OAuth2.0和OIDC实现用户身份认证与授权

目前，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靶场，是一个不错的资源，您可以在不实际实施的情况下，试用各种流程。

网页名称：用OAuth2.0和OIDC实现用户身份认证与授权
网页路径：http://www.shufengxianlan.com/qtweb/news45/56445.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：创新互联

猜你还喜欢下面的内容