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

  • 时间:
  • 浏览:1

肯能攻击者不能拦截肯能替换来自Client的一二个调用,它肯能会改变返回的用户信息,而客户端却无法感知类事情况表。这将允许攻击者通过简单地在正确的调用序列中交换用户标识符来模拟一二个幼稚的(naive)Client上的用户。通过在身份认证协议过程中(比如跟随OAuth的Token的颁发过程)直接从身份提供任务管理器池池中获取身份认证信息,并通过可校验的签名保护身份认证信息,都还还可以缓解类事点难题报告 。

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

事实上,有其他众所周知的配方都还还可以与特定的供应商进行合作,比如Facebook Connect、使用Twitter登录以及OpenID Connect(为Google的登录系统提供了支持)。哪些地方地方配方每个都换成了其他项目到OAuth中以创建身份认证协议,比如通用的profile API。都还还可以在那么OAuth的情况表下构建身份验证协议吗?当然都还还可以,就像有要是 种非巧克力软糖一样。随后大家今天在这里谈论的是专门针对基于OAuth2的身份认证,以及肯能总出 哪些地方难题报告 ,以及怎样才能确保安全和美味。

OpenId Connect是直接建立在OAuth2之上的,在大多数情况表下,部署在一二个基于OAuth的基础设施之上。它还使用JOSN签名和加密规范,用来在传递携带签名和加密的信息。OpenId Connect解决了上边讨论的要是 误区。

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

OAuth2为了允许各种不同的部署而编写,随后原先的设计并那么指定哪些地方地方部署怎样才能设置以及组件之间怎样才能互相了解,在OAuth买车人的世界中这是没难题报告 的。在使用OpenId Connect时,一二个通用的受保护的API部署在各种各样的Client和提供者中,所哪些地方地方地方都还要彼此互相了解不能运行。对于每个Client来说,不肯能随后了解有关每个提供任务管理器池池,以随后求每个提供者了解每个潜在的Client,这将大大削弱扩展性。

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

通过将Client的认证信息与Client都还还可以识别和验证的标识符同去传递给Client,都还还可以缓解此难题报告 ,从而允许客户端区分自身的身份认证与另一应用任务管理器池池的身份认证。通过在OAuth的过程中直接向Client传递一组身份认证信息,而都是 通过受OAuth保护的API原先的辅助机制来缓解它,从而解决Client在稍后的过程中注入未知来源的不可信的信息。

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

备注:原文标题是“User Authentication with OAuth 2.0”,觉得很糙不妥,原先要是 人对于AuthenticationAuthorization的认知都是 其他混淆,而OAuth2是一二个Authorization协议,而都是 Authentication的协议,故而在翻译的随后调整了原文的名称。同去提了一二个Pull Request(https://github.com/aaronpk/oauth.net/pull/154),我不知道会不不被接受。

此外,在用户不存在后,access token通常都是存在很长时间。记住,OAuth是一二个授权协议(delegation protocol),这对它的设计至关重要。这原因分析分析分析着,肯能一二个Client不不确保身份认证是有效的,那么简单的使用token获取用户属性是匮乏的,肯能OAuth保护的是资源,获取用户属性的API(identity API)通常那么措施 告诉你用户有无存在。

类事难题报告 好的反义词总出 ,是肯能此处讨论的身份认证的机制被明确的排除在OAuth的范围之内。OAuth定义了一二个那么特定格式的token(no specific token format),定义了一二个那么通用的范围(no common set of scopes)的access token,随后那么解决受保护资源怎样才能验证access token。

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

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

肯能Id token是授权服务器签名的,它还提供了在authorization code(c_hash)和access token(at_hash)上换成分离签名的位置,哪些地方地方hash都还还可以由Client来验证,同去仍保留authorization code和access token对Client不透明的语义,从而解决类事类的注入攻击。

另外一二个额外的威胁(非常危险)是当Client接受来自token endpoint的token时。这肯能会存在在使用implicit流程(类事流程中直接把acces token作为url的hash参数(译注:[认证授权] 1.OAuth2 授权 - 5.2.2 Access Token Response))中,随后Client不正确的使用state参数的随后。肯能应用任务管理器池池在不同的组件中传递 access token以“共享”访问权限的随后,也会存在此难题报告 。这里的难题报告 在于它开辟了一二个注入access token到应用任务管理器池池内控 (并肯能在应用任务管理器池池内控 泄露)的地方。肯能Client不通过一种机制验证access token,则它无法区分access token是有效的令牌还是攻击的令牌。

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

OpenID Connect是2014年初发布的开放标准,定义了一种基于OAuth2的可互操作的措施 来来提供用户身份认证。实际上,它是众所周知的巧克力软糖的配方,肯能被多数的专家们尝试和测试了。应用任务管理器池池好的反义词为每个潜在的身份提供任务管理器池池构建不同的协议,要是 都还还可以将一二个协议提供给多个提供任务管理器池池。肯能OpenId Connect是一二个开放标准,要是 都还还可以自由的那么任何限制的和知识产权难题报告 的来实现。

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

肯能access token都还还可以用于获取一组用户属性,随后拥有一二个有效的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)。

OAuth 2.0 规范定义了一二个授权(delegation协议,对于使用Web的应用任务管理器池池和API在网络上传递授权决策非常有用。OAuth被用在各钟各样的应用任务管理器池池中,包括提供用户认证的机制。这原因分析分析分析其他的开发者和API提供者得出一二个OAuth一种是一二个认证协议的错误结论,并将其错误的使用于此。让大家再次明确的指出:

在类事比喻中,OAuth是巧克力。这是一二个功能的原料,对其他不同的东西是至关重要的,甚至都还还可以买车人使用。认证更像是软糖,至少有其他成分还要以正确的措施 汇集在同去​​,使其成为肯能,OAuth你说歌词 是哪些地方地方成分之一(肯能是主要原料),但肯能也根本不还要参与其中。你还要一二个配方来说明说明怎样才能组合它们。

应该指出的是,Client不再还要使用access token,肯能Id token肯能中有 了解决身份认证所需的所有信息。然而,为了保持和OAuth的兼容性,OpenId Connect会同去提供Id token和acces token。

为了抵消类事情况表,OpenId Connect定义了一二个发现协议,它允许Client轻松的获取有关怎样才能和特定的身份认证提供者进行交互的信息。在买车人面,还定义了一二个Client注册协议,允许Client引入新的身份提供任务管理器池池(identity providers)。通过类事种机制和一二个通用的身份API,OpenId Connect都还还可以运行在互联网规模上运行良好,在那里那么任何一方随后知道对方的存在。

然而,OAuth那么告诉应用任务管理器池池上述任何信息。OAuth对用户那么任何说明,也那么说明怎样才能证明大家的存在,即使大家就在那里。对于OAuth的Client而言,它请求一二个token,得到一二个token,并用类事token访问其他API。但它我不知道是谁授权的应用任务管理器池池,以及甚至还有一二个用户在那里。实际上,OAuth的大每种难题报告 在于Client和被访问的资源之间的连接上在用户不存在的情况表下使用类事委托访问。这对于Client授权来说是好的,随后对于用户身份认证来说却非常糟糕,肯能认证还要选泽用户有无存在(以及大家是谁)。

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

为了帮助弄清楚这件事情,都还还可以通过一二个比喻来思考类事难题报告 :巧克力 VS 软糖。在一随后随后开始英文,这两件事情的本质是截然不同的:巧克力是一种原料,软糖要是 糖果。巧克力都还还可以用来做其他不同的事情,甚至都还还可以买车人使用。软糖都还还可以由其他不同的东西制成,其中一种肯能是巧克力,随后还要多种成分来制造软糖,甚至不不用到巧克力。随后,巧克力等于软糖是错误的,而巧克力等于巧克力软糖肯定是夸大其词的。

本文旨在帮助潜在的身份提供者怎样才能基于OAuth2构建用户身份认证。实际上,肯能你说歌词 “我有OAuth2,随后我还要身份认证”,那么请继续阅读。

都还还可以通过使用Authorization code来缓解类事点,随后非要通过授权服务器的token API(token endpoint)并使用一二个state的值来解决被攻击者猜中。

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

另外一二个难题报告 是,通过access token获取一组用户属性的OAuth API通常那么为返回的信息的受众做任何限制。换句话话说,很肯能有一二个幼稚的(naive)Client,从其他的Client拿到一二个有效的token来作为买车人的登录事件。毕竟令牌是有效的,对API的访问也会返回有效的用户信息。难题报告 在于那么用户做任何事情来证明用户存在,在类事情况表下,用户甚至都那么授权给幼稚的(naive)Client。

OpenID Connect Id Token是一二个签名的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的保护之外,还换成了一二个额外的保护层,以解决类事的模拟攻击。通过对此token的其他校验检查,Client都还还可以保护买车人免受几瓶常见的攻击。

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

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

基于OAuth 身份(identity)API的最难题报告 报告 在于,即使使用完全符合OAuth的机制,不同的提供任务管理器池池不可解决的会使用不同的措施 实现身份(identity)API。比如,在一二个提供任务管理器池池中,用户标识符肯能是用user_id字段来表示的,但在另外的提供任务管理器池池中则是用subject字段来表示的。即使哪些地方地方语义是等效的,也还要两份代码来解决。换句话说,觉得存在在每个提供任务管理器池池中的授权是相同的,随后身份认证信息的传输肯能是不同的。此难题报告 都还还可以在OAuth之上构建标准的身份认证协议来缓解,原先无论身份认证信息来自何处,都都还还可以用通用的措施 传输。