[OAuth2.1] OAuth2.1 的更新点粗略翻译

OAuth2.1

于2021年3月15日更新的OAuth2.1文档,相较于OAuth2.0有哪些区别呢？在此整理一下。

1. PKCE is required for all OAuth clients using the authorization code flow
2. Redirect URIs must be compared using exact string matching
3. The Implicit grant (response_type=token) is omitted from this specification
4. The Resource Owner Password Credentials grant is omitted from this specification
5. Bearer token usage omits the use of bearer tokens in the query string of URIs
6. Refresh tokens for public clients must either be sender-constrained or one-time use

翻译：

1. 所有使用授权码流的用户都需要PKCE参数
2. 重定向地址必须使用精确的字符串匹配
3. 隐式授权被移除
4. 资源所有者密码凭证授予被删除
5. 禁止在查询字符串(类似于get请求的参数)中携带bearer token
6. 刷新令牌必须是与用户绑定的或者一次性的

概要翻译，详细信息参见文末官方地址

1. 所有使用授权码流的用户都需要PKCE参数

PKCE出版于2015年,扩展了授权代码授予模式，保护认证流程的一部分发生在非TLS连接的攻击。例如,如果有一个本地应用程序的组件之间有通信就会发生这种情况。

PKCE需要一个额外的一次性代码生成和发送到OAuth服务器。这段代码验证请求没有被拦截或修改。

OAuth 2.1草案规范要求PKCE被用于每个授权码模式,防止授权代码被攻击者获取和被用来获得一个令牌。

2. 重定向地址必须使用精确的字符串匹配

我们或多或少的会配置一个或者多个重定向地址，这使得我么当启动一个新的服务时就需要去添加重定向地址。

例如,如果一个CI系统构建为每个特性分支一个应用程序,它可能的主机名dans-sample-application-1551.herokuapp.com,假设包含一个特性分支修复问题#1551。如果我想使用授权码模式,我需要更新我的OAuth服务器URI设置重定向地址使其包括URI: https://dans-sample-application-1551.herokuapp.com/oauth-callback.

与此同时，另一个问题#1552 问题来了，那同样的，我们需要添加一个重定向地址https://dans-sample-application-1552.herokuapp.com/oauth-callback。很明显，这并不方便，所以就需要一个这样的重定向地址：https://dans-sample-application-*.herokuapp.com/oauth-callback.

然而,允许通配符匹配重定向的URI是一个安全风险。如果重定向的URI匹配的是灵活的,攻击者可以向服务器发送用户开放的重定向控制它们,然后在一个恶意的目的地。
所以使用精确匹配定向URI可以消除这种风险,因为重定向URI总是一个已知值。

ps: 我特么看到一半还以为在夸模糊匹配多么好，看到最后才发现是在先扬后抑啊0.0

3. 隐式授权被移除

隐式授予方式在使用单页面应用时是不安全的，就等于你把access_token暴露出来了，你的access_token不是一次性使用的，它存在有效时间，在这有效时间内，你泄露了你的access_token,攻击者可以对你的程序发起千万亿次请求！
为什么不安全，请看：官方说明

4. 资源所有者密码凭证授予被删除

这种模式时OAuth2.0为了简化迁移OAuth兼容的服务的。虽然其可以使我们更好的迁移应用，但是这并不符合标准。毕竟,应用服务器完全访问用户的凭据,OAuth还旨在避免什么呢。
如果你有一个移动应用程序使用这个格兰特,你可以更新客户端使用一个授权代码模式并继续使用PKCE 或 继续使用OAuth 2.0来兼容你的系统。

5. 禁止在查询字符串(类似于get请求的参数)中携带Bearer token

Bearer token ,也被称为访问令牌,允许访问受保护的资源,因此必须是安全的。他们被称为不记名的令牌,因为仅仅拥有让你访问。他们就像一套房子的钥匙。当今时代,大多数jwt令牌。客户安全地存储它们,然后用它们来让应用程序服务器API调用。然后应用程序服务器使用令牌,以确保客户端调用API提供了适当的权限。

当第一次在RFC 6750中定义,令牌被允许在hearers,post的body里或查询字符串里。OAuth 2.1草案禁止发送在查询字符串Bearer token。

任何字符串URL,从来都不是私密的。页面上的JavaScript执行可以访问它。一个URL或组件可能会记录在服务器日志文件,浏览器缓存,或者浏览器历史中。

一般来说,如果你想安全的通过互联网传递信息,那就不能再URL中放任何东西。相反,使用TLS,把敏感信息在Body或HTTP头更好。

6. 刷新令牌必须是与用户绑定的或者一次性的

如果你需要访问资源超过一个access_token的生存时间,或如果你需要频繁访问,refresh_token可以帮助你。因此,你应该确保使用刷新令牌时要多加注意。禁止不同设备之间分享你的刷新令牌!

如果被攻击者获取，他们就可以随意创建access_token。你必须安全的使用你的刷新token。如何安全使用：参见：文章1，文章2

因此：OAuth 2.1草案为刷新令牌提供了两个选择:他们可以一次性使用或与发送方加密绑定。

参见：

• 官方对这些改动的解释
• OAuth2文档