【身份与访问控制工程】OAuth 2.1 与 PKCE：现代授权主路径
内容提要
某团队的单页应用在安全审计中发现access_token以URL fragment形式暴露，存在高风险。审计指出，攻击者可通过浏览器历史和日志获取token。OAuth 2.1通过废弃隐式授权和强制使用PKCE等措施提升安全性，确保公共客户端安全地使用授权码流程。PKCE通过动态生成挑战和答案，防止授权码被拦截，增强了OAuth的安全性。
关键要点
-
某团队的单页应用在安全审计中发现access_token以URL fragment形式暴露，存在高风险。
-
审计指出，攻击者可通过浏览器历史和日志获取token。
-
OAuth 2.1通过废弃隐式授权和强制使用PKCE等措施提升安全性。
-
PKCE通过动态生成挑战和答案，防止授权码被拦截，增强了OAuth的安全性。
-
OAuth 2.1的设计目标是合并最佳实践、删除不安全的授权方式，并将建议改为必须。
-
OAuth 2.1直接删除了implicit grant和ROPC，所有public client必须使用授权码流程加PKCE。
-
PKCE的适用范围扩展到所有public client，并且从推荐升级为必须。
-
OAuth 2.1要求redirect_uri精确匹配，禁止URL query string传递access_token。
-
OAuth 2.1建议对public client启用refresh_token rotation，以提高安全性。
-
PKCE通过动态生成的code_verifier和code_challenge增强了授权码流程的安全性。
延伸解读
OAuth 2.1 的安全改进
OAuth 2.1 通过废弃隐式授权和强制使用 PKCE，显著提升了安全性。隐式授权的风险在于 access_token 可能暴露在 URL 中，容易被攻击者获取。PKCE 则通过动态生成的挑战和答案，确保授权码在交换过程中不被拦截，从而增强了公共客户端的安全性。
PKCE 的重要性
PKCE 现在被要求在所有公共客户端中使用，这意味着即使没有 client_secret，客户端也能安全地使用授权码流程。这一变化不仅提高了安全性，还简化了开发者的实现过程，减少了因不当使用而导致的安全漏洞。
迁移到 OAuth 2.1 的挑战
虽然 OAuth 2.1 的设计并非破坏性变更，但现有系统的迁移仍然面临挑战。开发者需要更新客户端以支持授权码 + PKCE 流程，并确保 redirect_uri 的精确匹配。这可能需要对现有代码进行较大改动，尤其是在用户体验和安全性之间找到平衡。
延伸问答
OAuth 2.1相较于OAuth 2.0有哪些主要变化？
OAuth 2.1废弃了隐式授权和密码授权，强制所有公共客户端使用授权码流程加PKCE，并要求redirect_uri精确匹配，禁止在URL查询字符串中传递access_token。
PKCE的作用是什么？
PKCE通过动态生成挑战和答案，防止授权码被拦截，增强了OAuth的安全性，特别适用于没有client_secret的公共客户端。
OAuth 2.1如何提高公共客户端的安全性？
OAuth 2.1要求公共客户端必须使用PKCE，并建议启用refresh_token rotation，以提高安全性，防止token泄露。
OAuth 2.1对redirect_uri的要求是什么？
OAuth 2.1要求redirect_uri必须精确匹配，禁止使用前缀或模式匹配，以防止开放重定向攻击。
OAuth 2.1如何处理refresh_token的安全性？
OAuth 2.1建议对公共客户端启用refresh_token rotation，每次使用refresh_token时发放新的token并使旧的失效，以降低泄露风险。
OAuth 2.1中access_token的传递方式有哪些限制？
OAuth 2.1禁止在URL查询字符串中传递access_token，只允许通过Authorization header传递，以减少泄露风险。
