【OAuth2】二、OAuth2.1

前言

OAuth2.0现在越来越流行了，特别在微服务大行其道的情况下。不过OAuth2.0太老了， 最初的OAuth2.0规范于 2012 年 10 月以RFC 6749文档为蓝本发布，取代了 2010 年 4 月发布的 OAuth1.0，在发布OAuth2.0的时候，Vue、React还没有兴起，甚至连跨域资源共享CORS还不是正式的W3C标准。OAuth2.0面对如今飞速发展的移动互联网已经老态龙钟，跟不上时代了。好在OAuth2.0非常开放，开发者可以做很多自定义操作，它把很多“设计权限”下放给了开发者，经过开发者多年的实践，OAuth2.0存在的问题缺陷已经被修补了很多，甚至有些流程扩展让OAuth2.0更加健壮。

OAuth社区审时度势，起草了新的新的OAuth规范，被称作OAuth2.1，目前还处于草案阶段。在新的规范中将淘汰OAuth2.0的某些不安全的流程，补充OAuth2.0的不足。

OAuth2.1有什么变化

我想很多OAuth2开发者很想知道新的OAuth2.1都有什么变化，我这里列举了一些，当然受能力所限可能不太完整。

授权码+PKCE

我们都知道OAuth2.0的授权码模式是最安全的授权模式。但在非TLS链接发生时，该模式的部分授权流程可能被拦截导致“中间人攻击”。为了防止报文被修改，在授权码的基础上附加了一个PKCE流程RFC7636用于JavaScript单页应用，后面还出台了针对移动端的PKCE规范RFC8252。

隐式授权被移除

在单页应用中，隐式授权response_type=token会把令牌附着在URL中，前端应用会把令牌放在本次存储、会话存储、Cookie中，无论哪种方式都存在令牌泄露的风险。消除这种风险的技术成本高昂，因此我也不建议学习和使用这种方式。

密码模式被移除

密码模式起码在国内使用的非常多，每天都有大量的开发者咨询相关的细节。虽然这种模式好用，但它打破了委托授权的模式，降低了OAuth2的安全性。

它的流程非常像“网络钓鱼攻击”，想象一下应用程序随意的让你在一个平台的登录页面中输入另一个平台的密码，如果两个平台都是可信的，这样做也无可厚非，不过对于安全而言，这扩大了泄露的面积，这是一种反密码模式，用户密码可能有意无意就暴露出去了。而且用户无法控制授权的流程，虽然用户限制了scope，但是客户端程序依然提供了编程机会来打破用户的scope。如果在公共OAuth2客户端上使用密码模式，你的令牌端点也可能会被嗅探到，进而被暴力穷举。

密码模式诞生的时候，单页应用还没有兴起，它是一种为了解决遗留问题而采用的过渡方案。

对Refresh Token进行限制

**Refresh Token（刷新令牌）**允许客户端无需重新认证即可检索新的访问令牌。当访问资源的时间超过访问令牌的有效时间，访问的频率非常低的情况下这种机制很有帮助。Refresh Token通常比访问令牌寿命更长，因此它的安全更应该收到重视。

如果它们被攻击者获取，攻击者可以随意创建访问令牌，安全壁垒将形同虚设。 OAuth 2.1草案规范为Refresh Token提供了两个选项：它可以一次性使用，也可以对之进行加密以保证不在传输中暴露。

小结

虽然目前OAuth2.1还处于起草阶段，不过上面的变动基本已经确定，目的是让授权模型更加科学和安全。对于我们普通开发者而言，隐匿模式和密码模式可以放弃了，Spring Security已经弃用了相关的功能和后续的维护。对于单页应用尽量采用Authorization Code+PKCE模式；对于移动端也有针对性的PKCE方案；而对于IoT可以使用Device Code模式。