|
|
|
|
公众号矩阵

用OAuth 2.0和OIDC实现用户身份认证与授权

本文将和您探讨用于用户身份验证和授权的OAuth 2.0,以及基于OIDC的隐式与授权代码流程的相关基础知识。

作者:陈峻来源:51CTO|2021-09-17 09:00

【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示例:

  1. JSON 
  2.   "sub""AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4"
  3.   "name""Priya Rajagopal"
  4.   "email""priya.rajagopal@example.com"
  5.   "iss""https://pk-demo.okta.com/OAuth 2.0/default"
  6.   "aud""WuRuBAgABMP7_w4K9L-40Jhh"
  7.   "iat": 1622246311, 
  8.   "exp": 1624838311, 
  9.   "amr": [ 
  10.     "pwd" 
  11.   ] 

其中,

  • 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】

【编辑推荐】

  1. 鸿蒙官方战略合作共建——HarmonyOS技术社区
  2. 衡量网络安全计划健康状况的四个指标
  3. 倪光南:《数据安全法》为各行业数据安全提供了监管依据
  4. 中华人民共和国数据安全法(全文)
  5. 美国网络安全企业于2016年向阿联酋出售了iMessage漏洞利用工具
  6. 《数据安全法》释放哪些信号?专家解读来了
【责任编辑:华轩 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

带你轻松入门 RabbitMQ

带你轻松入门 RabbitMQ

轻松入门RabbitMQ
共4章 | loong576

44人订阅学习

数据湖与数据仓库的分析实践攻略

数据湖与数据仓库的分析实践攻略

助力现代化数据管理:数据湖与数据仓库的分析实践攻略
共3章 | 创世达人

14人订阅学习

云原生架构实践

云原生架构实践

新技术引领移动互联网进入急速赛道
共3章 | KaliArch

42人订阅学习

视频课程+更多

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微