某原生移动应用采用 OAuth 2.0 授权码流程。由于客户端无法安全保存固定密钥，设计者希望降低授权码被其他应用截获后换取令牌的风险。较合适的机制是（）。
PKCE 由客户端为每次授权生成随机 code_verifier，并在授权请求中发送其变换结果 code_challenge。令牌端点只有在 verifier 验证通过时才兑换授权码，使仅截获授权码的攻击者难以冒用。
选项分析
正确。PKCE 用一次性的 verifier/challenge 绑定授权请求和令牌兑换。
错误。公开客户端的安装包可被分析，硬编码固定 secret 不能提供可靠保密性。
错误。把令牌暴露在 URL 中会增加日志、历史记录和 Referer 泄露风险。
错误。放松重定向 URI 校验会扩大授权响应被劫持的风险。
本题为什么容易错
有同学把 PKCE 记成“移动端 client_secret”。实际上 verifier 是每次流程新生成的临时证明，不能用一串长期固定值代替。
简短答案
移动应用怎样用 PKCE 降低 OAuth 授权码被截获后的冒用风险，正确答案是 A（使用 PKCE：授权时提交 code_challenge，换令牌时提交对应的 code_verifier）。PKCE 由客户端为每次授权生成随机 code_verifier，并在授权请求中发送其变换结果 code_challenge。令牌端点只有在 verifier 验证通过时才兑换授权码，使仅截获授权码的攻击者难以冒用。
易混淆概念对比表
| 概念 | 本题判断 | 区别要点 | 记忆提示 |
|---|---|---|---|
| 使用 PKCE：授权时提交 code_challenge，换令牌时提交对应的 code_verifier | 本题正确答案 | 正确。PKCE 用一次性的 verifier/challenge 绑定授权请求和令牌兑换。 | 看到题干核心场景时优先联想到它 |
| 把固定 client_secret 直接写入安装包并长期不更换 | 本题干扰项 | 错误。公开客户端的安装包可被分析，硬编码固定 secret 不能提供可靠保密性。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
| 把访问令牌放进重定向 URI 的查询参数并公开记录 | 本题干扰项 | 错误。把令牌暴露在 URL 中会增加日志、历史记录和 Referer 泄露风险。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
| 取消 redirect_uri 校验，只要授权码正确就发放令牌 | 本题干扰项 | 错误。放松重定向 URI 校验会扩大授权响应被劫持的风险。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
本题易混淆选项怎么区分
- 把固定 client_secret 直接写入安装包并长期不更换：错误。公开客户端的安装包可被分析，硬编码固定 secret 不能提供可靠保密性。
- 把访问令牌放进重定向 URI 的查询参数并公开记录：错误。把令牌暴露在 URL 中会增加日志、历史记录和 Referer 泄露风险。
- 取消 redirect_uri 校验，只要授权码正确就发放令牌：错误。放松重定向 URI 校验会扩大授权响应被劫持的风险。
知识点详解
PKCE 最初重点解决原生应用授权码拦截，如今也广泛用于授权码流程。客户端先生成随机 code_verifier，再计算 code_challenge；授权服务器保存 challenge，令牌端点收到 verifier 后重新计算并比对。PKCE 需与 TLS、精确的重定向 URI 校验、state 防跨站请求伪造以及安全的令牌存储配合，不能单独承担全部 OAuth 安全责任。
备考速记
先交 challenge，后证 verifier；偷到 code，没有 verifier 也换不了 token。
PKCE 在移动应用安全场景中的作用
PKCE在本题中的核心价值，是解决“某原生移动应用采用 OAuth 2.0 授权码流程。由于客户端无法安全保存固定密钥，设计者希望降低授权码被其他应用截获后换取令牌的风险。较合适的机制是（）”这个场景问题。复习时不要只背选项名称，还要理解它为什么适用于该场景，以及它能解决哪类安全、流程或管理问题。
同类题怎么考
- 公开客户端无法安全保存密钥，选择 PKCE。
- 授权码泄露场景中，判断攻击者为什么仍不能兑换令牌。
PKCE 在信息安全工程师软考中的考法
软考选择题通常不会只考概念定义，还会把PKCE放到移动应用安全场景中，要求判断它的作用、适用范围或与相近概念的区别。遇到这类题时，先抓住题干中的业务场景，再看哪个选项最能解决该场景下的核心问题。
解题思路
原生应用装在用户设备上，安装包里的固定 secret 很难称得上秘密。PKCE 换了个思路：客户端先生成一段高熵随机 verifier，只把它的 challenge 发到授权端；拿授权码换令牌时再交出原始 verifier。攻击者即使截到授权码，没有 verifier 也过不了令牌端点校验。它解决的是授权码被截获后的冒用问题，不是替代 TLS。
考点定位
PKCE 不是另一份长期客户端密钥，而是每次授权临时生成的一对 verifier/challenge，用来把授权请求与后续令牌兑换绑定起来。
易错提醒
- 使用可预测或长度不足的 code_verifier。
- 用 plain 方式却没有充分理由，未优先采用 S256 challenge。
- 认为有 PKCE 就可以不用 TLS、state 或严格 redirect_uri。
备考提示
- 按两步画流程：授权请求带 challenge，令牌请求带 verifier。
- 把 PKCE、state、nonce 分开记：它们针对的风险和所处协议层次不同。
你可能还想了解
- PKCE 和 client_secret 有什么区别？
- code_verifier 为什么要每次随机生成？
- 有 PKCE 后还需要 state 和 TLS 吗？
本文小结
PKCE 让客户端在授权时提交 code_challenge，兑换令牌时证明对应的 code_verifier。攻击者只截获授权码仍难换取令牌，尤其适合无法安全保存固定密钥的公开客户端。