【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会相继生成,并被配置到请求身份验证的应用和客户端上。
当用户(在OAuth 2.0中也称为“资源所有者”)点击应用上的“使用Facebook登录”按钮时,应用程序会向授权服务器的登录URL,发送授权请求。通常,Facebook之类的授权请求会包括许多参数。为简洁起见,我们省去RFC6749规定的完整参数列表,仅包含如下参数:
- client_id—为授权服务器排他地标识了应用程序。
- response_type--表明客户端所需的授权代码。
- redirect_uri--指定授权服务器将通过重定向进行后续身份验证的URL。
Facebook的授权服务器会提示用户输入他们的用户名和密码,并以可选的方式要求回答验证所需的安全问题。
一旦通过身份验证,用户可能会看到一张“资源同意表”,其中列出了应用程序想要访问到的Facebook资源集(例如,用户的公开个人资料等)。
- 这些已同意的资源集是通过对初始授权请求中的scope参数所指定的。
一旦用户被授权访问其请求的资源,用户将会被重定向回带有授权代码的应用程序。
- 其中,授权服务器对于用户进行重定向的URL,是通过redirect_uri参数指定的,该参数也被包含在最初的授权请求中。
然后,应用程序会与客户端及授权服务器交换授权代码,并获取opaque访问令牌(或刷新令牌),并将client_id和client_secret作为请求的一部分进行传递。
最后,应用程序可以使用访问令牌,去访问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】