【身份与访问控制工程】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.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传递，以减少泄露风险。
