概述

一般Oauth2.0协议的授权码模式在统一认证中用的比较多，在实际的使用中，往往还会在获取令牌的时候，多一个参数，即client_secret来保证认证的安全

在研究gitlab鉴权的时候，发现了一种Authorization code with Proof Key for Code Exchange (PKCE) 方式。

docs.gitlab.com/ee/api/oaut…

详情

相比OAuth2.0授权码模式，就是在获取授权码code的时候，多了code_challenge和code_challenge_method两个参数，在获取access_token令牌的时候，多了code_verifier一个参数。 其中

1. code_verifier 是一种43-128个字符的随机字符串，由 A-Z, a-z, 0-9, -, ., _, and ~组成；

2. CODE_CHALLENGE 是VERIFIER 通过SHA256摘要得到的一个Base64编码的字符串;

想了解更多的可以看一下 Oauth2.1的认证框架

datatracker.ietf.org/doc/html/dr…

主要的变化：

The major differences from OAuth 2.0 are listed below.

• PKCE is required for all OAuth clients using the authorization code flow
• Redirect URIs must be compared using exact string matching
• The Implicit grant (response_type=token) is omitted from this specification
• The Resource Owner Password Credentials grant is omitted from this specification
• Bearer token usage omits the use of bearer tokens in the query string of URIs
• Refresh tokens for public clients must either be sender-constrained or one-time use
• The definitions of public and confidential clients have been simplified to only refer to whether the client has credentials

主要点：

1. 引入PKCE。至于PKCE可以看一下详细介绍：

www.rfc-editor.org/rfc/rfc7636

引入PKCE的主要原因就是因为OAuth2.0的授权码模式比较容易收到授权码拦截攻击。这个攻击就是恶意客户端拦截认证服务器返回的授权码，然后通过拦截的授权码获取到令牌，从而获取到用户的隐私信息；  

授权码交换证明密钥 （PKCE） RFC 于 2015 年发布，它扩展了授权代码授权，以防止部分授权流通过非 TLS 连接发生时受到攻击。例如，在本机应用程序的组件之间。如果 TLS 存在漏洞，或者路由器固件已遭到入侵，并且正在欺骗 DNS 或从 TLS 降级到 HTTP，也可能发生此攻击。PKCE 需要将额外的一次性代码发送到 OAuth 服务器。这用于验证请求是否未被拦截或修改。  

1. 重定向URI使用精确匹配。

在配置重定向地址时，往往支持通配符，这样肯定会很方便；比如有这样的一个场景，我们最终重定向的地址需要携带一些动态参数，这些动态参数往往被最终页面用来逻辑判断，从而执行一些业务逻辑；在认证过程中，如果携带了这些动态菜蔬，那么如果不支持同配符号，那么就与我们配置的重定向URIne都不匹配，导致认证失败；

但是，允许重定向 URI 的此类通配符匹配存在安全风险。如果重定向 URI 匹配是灵活的，攻击者可以将用户重定向到由他们控制的开放重定向服务器，然后重定向到恶意目标;虽然这需要以某种方式破坏请求，但对重定向 URI 使用精确匹配可以消除此风险，因为重定向 URI 始终是已知值。

1. 限制刷新令牌。

刷新令牌允许客户端检索新的访问令牌，而无需重新身份验证。如果需要访问资源的时间比访问令牌的访问时间更长，或者需要不频繁的访问（例如登录电子邮件数月或数年），这将非常有用。因此，它们的生存期通常比访问令牌更长。

如果它们被攻击者获取，攻击者可以随意创建访问令牌。显然，在这一点上，访问令牌保护的资源将不再安全。

OAuth 2.1 草案规范为刷新令牌提供了两个选项：它们可以是一次性使用的，也可以通过加密绑定到发送方。

• 一次性使用意味着在使用刷新令牌（称为刷新令牌 A）检索访问令牌后，该令牌将失效。当然，OAuth 服务器可以发送新的刷新令牌（称为刷新令牌 B）以及请求的访问令牌。在这种情况下，一旦新传送的访问令牌过期，客户端可以使用刷新令牌 B 请求另一个访问令牌，接收新的访问令牌和新的刷新令牌 C，依此类推。更改为一次性使用刷新令牌可能需要更改客户端代码，以便在每次刷新时存储新的刷新令牌。

• 另一个是确保 OAuth 服务器以加密方式将刷新令牌绑定到客户端。这个还没太理解。

总结

• OAuth 2.1的最新规范旨在将OAuth 2.0中制定的变更和调整整合到一个文件中，以提高默认安全性和作为参考文档。
• OAuth 2.1将删除某些风险较高的授权方式，如隐式授权和资源所有者密码凭证授权，并规定使用PKCE来加强授权码授权的安全性。
• 结合OAuth 2.0安全最佳实践文件，OAuth 2.1要求对重定向URI进行精确字符串匹配，避免在查询字符串中使用持有人令牌等。

参考

oauth.net/2.1/

What's new in OAuth 2.1? (fusionauth.io)