authentication oauth介绍 - 为什么当“隐式”流程运行良好时,OAuth2中存在“授权码”流?




auth是什么 oauth怎么读 (4)

在“隐式”流程中,在资源所有者(即用户)授予访问权限后,客户端(可能是浏览器)将获得访问令牌。

然而,使用“授权码”流程,客户端(通常是Web服务器)在资源所有者(即用户)授予访问权限后才会获得授权码。 使用该授权码,客户端再次调用API,将client_id和client_secret与授权码一起传递,以获取访问令牌。 这里都有很好的描述

两个流程都具有完全相同的结果:访问令牌。 但是,“隐式”流程要简单得多。

问题: 为什么要打扰“授权码”流程,当“隐式”流程接缝良好时? 为什么不为Web服务器使用“隐式”?

这对提供者和客户来说都是更多的工作。


Answers

来自OAuth规范的第4.2节:

隐式授权类型用于获取访问令牌(它不支持发布刷新令牌),并且针对已知操作特定重定向URI的公共客户端进行了优化。 这些客户端通常使用JavaScript等脚本语言在浏览器中实现。

作为基于重定向的流程,客户端必须能够与资源所有者的用户代理(通常是Web浏览器)进行交互,并且能够从授权服务器接收传入请求(通过重定向)。

与客户端对授权和访问令牌分别请求的授权代码授予类型不同,客户端根据授权请求接收访问令牌。

隐式授权类型不包括客户端认证,并且依赖于资源所有者的存在和重定向URI的注册。 由于访问令牌编码为重定向URI,因此可能会暴露给位于同一设备上的资源所有者和其他应用程序。

所以我们可以将其结合起来:

  1. 这是针对公开OAuth的,即当客户不需要注册并且没有它自己的客户机密时。 但是,auth服务器会检查重定向url,这对于安全性来说确实够用了。

  2. 访问令牌出现在浏览器的地址栏中,因此用户可以复制该URL并发送给其他人,并且它也会以用户的身份登录,即它类似于会话固定。 但浏览器使用替换历史记录进行额外的重定向以从URL中删除哈希片段。 黑客通过嗅探HTTP流量窃取访问令牌也是可能的,但这可以通过HTTPS轻松保护。 某些恶意浏览器扩展可以通过地址栏访问网址,但这最终会导致破损的HTTPS证书等不良情况。 甚至Auth代码流在这里也无法帮助。 所以我能看到的是通过URL的哈希碎片传递访问令牌是绝对安全的。

  3. 临时访问令牌和刷新令牌的分离在使用HTTPS时没有用处,并且即使在原始HTTP上也没有那么实用。 但客户端通过隐式流不能接收刷新令牌的事实也是无稽之谈。

因此,我认为我们应该引入一个新的授权流程“安全隐含”,它严格地在https上运行,允许刷新令牌(或者我们应该删除它们),并且比Auth Cose授权流程更可取


tl; dr:这全是因为安全原因。

OAuth 2.0想要符合这两个标准:

  1. 您希望允许开发人员使用非HTTPS重定向URI,因为并非所有开发人员都具有启用了SSL的服务器,并且如果他们这样做,它并不总是正确配置(非自签名,可信SSL证书,同步服务器时钟...)。
  2. 您不希望黑客通过拦截请求来窃取访问/刷新令牌。

以下详情:

由于安全原因,隐式流只能在浏览器环境中使用:

隐式流中 ,访问令牌直接作为散列片段传递(而不是URL参数)。 散列片段的一个重要事情是,一旦你跟随一个包含散列片段的链接,只有浏览器知道散列片段。 浏览器将散列片段直接传递到目标网页(重定向URI /客户端的网页)。 哈希片段具有以下属性:

  • 它们不是HTTP请求的一部分,因此它们不能被服务器读取,因为它们不能被中间服务器/路由器拦截(这很重要)。
  • 它们只存在于浏览器 - 客户端 - 所以读取哈希片段的唯一方法是使用运行在页面上的JavaScript。

这使得将访问令牌直接传递给客户端成为可能,而没有被中间服务器拦截的风险。 这只是可能的客户端,需要JavaScript运行客户端使用访问令牌的警告。

授权代码流中 ,由于URL参数是HTTP请求的一部分,因此无法直接在URL参数中传递访问令牌,因此,您的请求可能通过的任何中间服务器/路由器(可能为数百个)都能够如果您未使用en加密连接(HTTPS),则允许读取访问令牌,即允许所谓的中间人攻击(Man-in-the-middle)攻击。

直接在URL参数中传递访问令牌在理论上是可能的,但是认证服务器必须确保重定向URI使用带有TLS加密的HTTPS和“可信”SSL证书(通常来自不是免费的证书颁发机构)确保目标服务器是合法的,并且HTTP请求已完全加密。 让所有开发人员购买SSL证书并在其域中正确配置SSL将是一个巨大的痛苦,并会大大减缓采用率。 这就是为什么提供中间一次性使用的“授权代码”,只有合法的接收者才能交换(因为你需要客户端的密码),并且代码对于潜在的黑客截获未加密事务的请求是无用的(因为他们不知道客户的秘密)。

你也可以争辩说,隐式流程不太安全,有潜在的攻击媒介,如重定向时欺骗域名 - 例如劫持客户端网站的IP地址。 这是为什么隐式流只授予访问令牌(应该有有限的时间使用)并且永远不刷新令牌(其时间无限)的原因之一。 为了解决这个问题,我建议您尽可能将网页托管在支持HTTPS的服务器上。


隐式流程使得整个流程非常容易,但也不太安全
由于通常在浏览器中运行的JavaScript的客户端应用程序不太受信任,因此不会返回用于长期访问的刷新令牌。
您应该将此流程用于需要对用户数据进行临时访问(几个小时)的应用程序。
将访问令牌返回给JavaScript客户端也意味着您的基于浏览器的应用程序需要格外小心 - 考虑可能会将访问令牌泄露给其他系统的XSS攻击。

https://labs.hybris.com/2012/06/05/oauth2-the-implicit-flow-aka-as-the-client-side-flow


我会在这里添加一些我不认为在以上答案中明确表达的内容:

  • 授权代码流允许最终的访问令牌永远不会到达,也不会被浏览器/应用程序存储在机器上 。 临时授权码通过浏览器/应用程序提供给机器,然后发送到服务器。 然后,服务器可以使用完整的访问令牌进行交换,并可以访问API等。具有浏览器的用户只能通过带令牌的服务器访问API。
  • 隐式流只能涉及两方, 最终访问令牌通过浏览器/应用程序存储在客户端上。 如果这个浏览器/应用程序受到威胁,那么它们的auth-token可能会很危险。

tl; dr如果不信任用户计算机持有令牌但信任自己的服务器,则不使用隐式流。







authentication oauth oauth-2.0