[认证授权] 3.基于OAuth2的认证(译)

  • 时间:
  • 浏览:1

累似 问提不言而喻经常总出 ,是不可能 此处讨论的身份认证的机制被明确的排除在OAuth的范围之内。OAuth定义了另3个 不都可不能能特定格式的token(no specific token format),定义了另3个 不都可不能能通用的范围(no common set of scopes)的access token,而且不都可不能能处理受保护资源如何验证access token。

事实上,有一些众所周知的配方前要与特定的供应商进行相互协作,比如Facebook Connect、使用Twitter登录以及OpenID Connect(为Google的登录系统提供了支持)。哪此配方每个都加进去去了一些项目到OAuth中以创建身份认证协议,比如通用的profile API。前要在不都可不能能OAuth的情况下构建身份验证协议吗?当然前要,就像有全都种非巧克力软糖一样。而且大伙今天在这里谈论的是专门针对基于OAuth2的身份认证,以及不可能 经常总出 哪此问提,以及如何确保安全和美味。

本文版权归作者和博客园共有,欢迎转载,但未经作者同意前要保留此段声明,且在文章页面明显位置给出原文连接,而且保留追究法律责任的权利。

OAuth2为了允许各种不同的部署而编写,而且原本的设计并不都可不能能指定哪此部署如何设置以及组件之间如何互相了解,在OAuth此人 的世界中这是没问提的。在使用OpenId Connect时,另3个 通用的受保护的API部署在各种各样的Client和提供者中,所有哪此都前要彼此互相了解不能运行。对于每个Client来说,无需可能 如果了解有关每个提供应用多多线程 ,而且要求每个提供者了解每个潜在的Client,这将大大削弱扩展性。

不可能 access token前要用于获取一组用户属性,而且拥另3个 有效的access token作为身份认证的证明也是很诱人的。在一些情况下,累似 假设是成立的,不可能 在授权服务器商经过身份认证的用户上下文中,token是如果被创建的。而且在OAuth中,这并都会获取access token的唯一法律法律最好的办法,Refresh Token和assertions(Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants:https://tools.ietf.org/html/rfc7521)前要在用户不指在的情况下获取access token。而在一些情况下,用户无需身份验证即可获得access token(译注:比如[认证授权] 1.OAuth2授权 - 5.4 Client Credentials Grant)。

不可能 Id token是授权服务器签名的,它还提供了在authorization code(c_hash)和access token(at_hash)加进去去进去分离签名的位置,哪此hash前要由Client来验证,一并仍保留authorization code和access token对Client不透明的语义,从而处理累似 类的注入攻击。

另外另3个 额外的威胁(非常危险)是当Client接受来自token endpoint的token时。这不可能 会指在在使用implicit流程(累似 流程中直接把acces token作为url的hash参数(译注:[认证授权] 1.OAuth2 授权 - 5.2.2 Access Token Response))中,而且Client不正确的使用state参数的如果。不可能 应用应用多多线程 在不同的组件中传递 access token以“共享”访问权限的如果,也会指在此问提。这里的问提在于它开辟了另3个 注入access token到应用应用多多线程 内外部(不言而喻可能 在应用应用多多线程 内外部泄露)的地方。不可能 Client不通过两种机制验证access token,则它无法区分access token是有效的令牌还是攻击的令牌。

OpenID Connect Id Token是另3个 签名的JSON Web Token(JWT:RFC7519),它和OAuth access token一并提供给Client应用应用多多线程 。Id Token中有 一组关于身份认证会话的声明(claim),包括用户的标识(sub)、颁发令牌的提供应用多多线程 的标识符(iss)、以及创建此标识的Client的标识符(aud)。此外,Id Token还中有 token的有效生存期(通常非常短)以及一些相关的上下文信息。不可能 Client知道Id Token的格式,而且它能直接分挥发token的内容而无需依赖内外部服务。此外,OpenId Connect还颁发access token给Client,允许Client保持对token的不透明,不可能 这是属于OAuth规范的一每种。最后,token两种是由提供应用多多线程 的私钥进行签名的,除了在获取token中受TLS的保护之外,还加进去去了另3个 额外的保护层,以处理累似 的模拟攻击。通过对此token的一些校验检查,Client前要保护此人 免受少量常见的攻击。

然而,OAuth不都可不能能告诉应用应用多多线程 上述任何信息。OAuth对用户不都可不能能任何说明,可是 都可不能能说明如何证明大伙的指在,即使大伙就在那里。对于OAuth的Client而言,它请求另3个 token,得到另3个 token,并用累似 token访问一些API。但它我可是 知道是谁授权的应用应用多多线程 ,以及甚至还另3个 用户在那里。实际上,OAuth的大每种问提在于Client和被访问的资源之间的连接上在用户不指在的情况下使用累似 委托访问。这对于Client授权来说是好的,而且对于用户身份认证来说却非常糟糕,不可能 认证前要选者用户有无指在(以及大伙是谁)。

此问提的根源在于Client都会OAuth access token的预期受众。相反, 它是该token的授权提出者, 而受众实际上是受保护的资源。受保护的资源通常不都可不能能够仅通过token的单独指在来判断用户有无指在, 不可能 oauth 协议的性质和设计, 在客户端和受保护资源之间的连接上用户是不可用的。为了应对累似 点, 前要另3个 针对客户两种的假象,这前要通过定义另3个 双重目的(dual-purposing)的Client前要解析和理解的access token来完成。而且不可能 一般的OAuth不都可不能能为access token两种定义特定的格式货内外部,而且诸如OpenId Connect的ID Token和Facebook Connect的Signed在响应中提供另3个 每种的标记,它将和access token一并发送给Client中。这前要使得Client对主要的access token保持不透明,就像常规的OAuth中的那样。

OpenId Connect是直接建立在OAuth2之上的,在大多数情况下,部署在另3个 基于OAuth的基础设施之上。它还使用JOSN签名和加密规范,用来在传递携带签名和加密的信息。OpenId Connect处理了里面讨论的全都误区。

另外另3个 问提是,通过access token获取一组用户属性的OAuth API通常不都可不能能为返回的信息的受众做任何限制。换句话话说,很不可能 另3个 幼稚的(naive)Client,从一些的Client拿到另3个 有效的token来作为此人 的登录事件。毕竟令牌是有效的,对API的访问也会返回有效的用户信息。问提在于不都可不能能用户做任何事情来证明用户指在,在累似 情况下,用户甚至都不都可不能能授权给幼稚的(naive)Client。

本文旨在帮助潜在的身份提供者如何基于OAuth2构建用户身份认证。实际上,不可能 跟跟我说“我有OAuth2,如何你前要前要身份认证”,不都可不能能请继续阅读。

基于OAuth 身份(identity)API的最大问提在于,即使使用完整符合OAuth的机制,不同的提供应用多多线程 不可处理的会使用不同的法律法律最好的办法实现身份(identity)API。比如,在另3个 提供应用多多线程 中,用户标识符不可能 是用user_id字段来表示的,但在另外的提供应用多多线程 中则是用subject字段来表示的。即使哪此语义是等效的,也前要两份代码来处理。换句话说,着实 指在在每个提供应用多多线程 中的授权是相同的,而且身份认证信息的传输不可能 是不同的。此问提前要在OAuth之上构建标准的身份认证协议来缓解,原本无论身份认证信息来自何处,前要用通用的法律法律最好的办法传输。

除了Id token中有 的信息之外,还定义了另3个 中有 当前用户信息的标准的受保护的资源。如上所述,哪此信息都会身份认证的一每种,可是 提供附加的标识信息。比如说应用应用多多线程 提示说“早上好:Jane Doe”,总比说“早上好:9XE3-JI34-00132A”要友好的多。它提供了一组标准化的属性:比如profile、email、phone和address。OpenId Connect定义了另3个 特殊的openid scope,前要通过access token来开启Id token的颁发以及对UserInfo Endpoint的访问。它前要和一些scope一并使用而不指在冲突。这允许OpenId Connect和OAuth平滑的共存。

应该指出的是,Client不再前要使用access token,不可能 Id token不可能 中有 了处理身份认证所需的所有信息。然而,为了保持和OAuth的兼容性,OpenId Connect会一并提供Id token和acces token。

此外,在用户不指在后,access token通常都会指在很长时间。记住,OAuth是另3个 授权协议(delegation protocol),这对它的设计至关重要。这原因分析分析着分析,不可能 另3个 Client无需确保身份认证是有效的,不都可不能能简单的使用token获取用户属性是欠缺的,不可能 OAuth保护的是资源,获取用户属性的API(identity API)通常不都可不能能法律法律最好的办法告诉你用户有无指在。

在累似 比喻中,OAuth是巧克力。这是另3个 功能的原料,对一些不同的东西是至关重要的,甚至前要此人 使用。认证更像是软糖,共要有一些成分前要以正确的法律法律最好的办法汇集在一并​​,使其成为不可能 ,OAuth跟我说是哪此成分之一(不可能 是主要原料),但不可能 也根本不前要参与其中。你前要另3个 配方来说明说明如何组合它们。

即使拥有哪此强大的身份认证功能,OpenId Connect(通过设计)仍然与纯粹的OAuth2兼容,使其前要在开发人员花费最小代价的情况下部署在在OAuth系统之上。实际上,不可能 服务不可能 使用了OAuth和JOSE规范(以及JWT),该服务以及前要很好的支持OpenId Connect了。

原文成文应该时比较早,一些信息不可能 过时了,我做了每种的删减,现在OpenId Connect不可能 成为了另3个 非常庞大的协议族了,有全都相关的辅助协议来完善认证授权的相关需求。OpenId Connect具体的信息参见这里:http://openid.net/connect/。此人 翻译水平一般,如有错误之处,欢迎指正!

为了抵消累似 情况,OpenId Connect定义了另3个 发现协议,它允许Client轻松的获取有关如何和特定的身份认证提供者进行交互的信息。在此人 面,还定义了另3个 Client注册协议,允许Client引入新的身份提供应用多多线程 (identity providers)。通过这两种机制和另3个 通用的身份API,OpenId Connect前要运行在互联网规模上运行良好,在那里不都可不能能任何一方如果知道对方的指在。

为了帮助弄清楚这件事情,前要通过另3个 比喻来思考累似 问提:巧克力 VS 软糖。在一如果如果如果结束,这两件事情的本质是截然不同的:巧克力是两种原料,软糖可是 糖果。巧克力前要用来做一些不同的事情,甚至前要此人 使用。软糖前要由一些不同的东西制成,其中两种不可能 是巧克力,而且前要多种成分来制造软糖,甚至无需用到巧克力。而且,巧克力等于软糖是错误的,而巧克力等于巧克力软糖肯定是夸大其词的。

OAuth 2.0 规范定义了另3个 授权(delegation协议,对于使用Web的应用应用多多线程 和API在网络上传递授权决策非常有用。OAuth被用在各钟各样的应用应用多多线程 中,包括提供用户认证的机制。这原因分析分析着一些的开发者和API提供者得出另3个 OAuth两种是另3个 认证协议的错误结论,并将其错误的使用于此。你前要们再次明确的指出:

另外另3个 的混淆的因素,另3个 OAuth的过程通常中有 在一些认证的过程中:资源所有者在授权步骤中向授权服务器进行身份验证,客户端向令牌端点中的授权服务器进行身份验证,不可能 还有一些的。OAuth协议中的哪此认证事件的指在不都可不能能够说明OAuth协议两种不能可靠地传送认证。(译注:我着实 不可能 作者想表达的是着实 OAuth是哪此认证事件的消费者,但却都会生产者,全都不都可不能能不可能 使用了认证,就等同于OAuth前要直接提供认证。)

事实证明尽管不都可不能能,还有一些事情前要和OAuth一并使用,以便在授权和授权协议之上创建身份认证协议。几乎在所有的哪此情况下,OAuth的核心功能都将保持不变,而指在的事件是用户将大伙的身份委派给大伙正在尝试登录的应用应用多多线程 。而且,客户端应用应用多多线程 成为身份API的消费者,从而找经常总出 前授权给客户端的用户。以累似 法律法律最好的办法建立身份验证的另3个 主要好处是允许管理最终用户的同意,这在互联网规模的跨域身份联合中是非常重要的。原本重要的好处是,用户前要一并将访问一些受保护的API委托给大伙的身份,使应用应用多多线程 开发人员和最终用户管理更简单。通过另3个 调用,应用应用多多线程 前要找出用户有无登录,应该调用哪此用户,下载照片进行打印,并将更新发布到其消息流。累似 简单性是非常有吸引力的,但当这两件事情一并进行时,一些开发人员将这另3个 功能混为一谈。

通过将Client的认证信息与Client前要识别和验证的标识符一并传递给Client,前要缓解此问提,从而允许客户端区分自身的身份认证与另一应用应用多多线程 的身份认证。通过在OAuth的过程中直接向Client传递一组身份认证信息,而都会通过受OAuth保护的API原本的辅助机制来缓解它,从而处理Client在稍后的过程中注入未知来源的不可信的信息。

前要通过使用Authorization code来缓解累似 点,而且不都可不能能通过授权服务器的token API(token endpoint)并使用另3个 state的值来处理被攻击者猜中。

OpenID Connect是2014年初发布的开放标准,定义了两种基于OAuth2的可互操作的法律法律最好的办法来来提供用户身份认证。实际上,它是众所周知的巧克力软糖的配方,不可能 被多数的专家们尝试和测试了。应用应用多多线程 不言而喻为每个潜在的身份提供应用多多线程 构建不同的协议,可是 前要将另3个 协议提供给多个提供应用多多线程 。不可能 OpenId Connect是另3个 开放标准,全都前要自由的不都可不能能任何限制的和知识产权问提的来实现。

即使使用OAuth来构建身份验证协议是非常有不可能 的,而且在身份提供者不可能 身份消费者方面,有一些事情不可能 会让哪此人 脱节。本文中描述的做法旨在通知身份提供商的潜在的常见风险,并向消费者通报在使用基于OAuth的身份认证系统时可处理的常见错误。

不可能 攻击者不能拦截不可能 替换来自Client的另3个 调用,它不可能 会改变返回的用户信息,而客户端却无法感知累似 情况。这将允许攻击者通过简单地在正确的调用序列中交换用户标识符来模拟另3个 幼稚的(naive)Client上的用户。通过在身份认证协议过程中(比如跟随OAuth的Token的颁发过程)直接从身份提供应用多多线程 中获取身份认证信息,并通过可校验的签名保护身份认证信息,前要缓解累似 点问提。

在用户访问另3个 应用应用多多线程 的上下文环境中认证会告诉应用应用多多线程 当前用户是谁以及其有无指在。另3个 完整的认证协议不可能 都会告诉你一些关于此用户的相关属性,比如唯一标识符、电子邮件地址以及应用应用多多线程 说“早安”时所前要的内容。认证是关于应用应用多多线程 中指在的用户,而互联网规模的认证协议前要不能跨网络和安全边界来执行此操作。

不可能 身份认证通常指在在颁发access token的如果, 而且使用access token作为身份认证的证明是非常诱人的。然而, 仅仅拥另3个 access token并不都可不能能告诉Client任何东西。在OAuth 中, token被设计为对Client不透明(译注:上一篇[认证授权] 2.OAuth2授权(续) & JSON Web Token中有 介绍), 但在用户身份认证的上下文环境中, Client前要不能从token中派生一些信息。

混乱的根源来自于在认证协议的内内外部实际上使用了OAuth,开发人员都看OAuth组件并与OAuth流程进行交互,并假设通过简单地使用OAuth,大伙就前要完成用户认证。这不仅都会事情的真相,而且对服务提供商,开发人员以及最终用户而言都会危险的事情。

原作者:Justin Richer 。文章地址: https://oauth.net/articles/authentication/。

备注:原文标题是“User Authentication with OAuth 2.0”,着实 不如何不妥,原本全都人对于AuthenticationAuthorization的认知都会一些混淆,而OAuth2是另3个 Authorization协议,而都会Authentication的协议,故而在翻译的如果调整了原文的名称。一并提了另3个 Pull Request(https://github.com/aaronpk/oauth.net/pull/154),我可是 知道会无需被接受。