移动端必须用PKCE而非常规OAuth2授权码流，因其无法安全保存client_secret，而PKCE通过动态code_verifier/challenge机制将信任从密钥保密转为运行时状态不可预测，截获code亦无法换token；RFC 7636强制要求。
为什么移动端必须用PKCE而不是常规OAuth2授权码流
因为移动端App无法安全保存client_secret——它会被反编译提取，导致授权服务器信任被绕过。PKCE通过动态生成code_verifier和对应code_challenge，把“客户端可信”从“密钥保密”转移到“运行时状态不可预测”，从根本上堵住这个漏洞。
关键点在于：即使攻击者截获了authorization_code，没有原始code_verifier就无法换取access_token。这是RFC 7636强制要求的移动端最佳实践。
code_verifier怎么生成才合规
必须是43–128字符的base64url编码随机字符串（不含+、/、=），且只用一次。Python标准库不直接支持base64url，得手动替换。
- 别用
secrets.token_urlsafe(32)直接当code_verifier——它可能含-或_，虽常见但不严格符合RFC；更稳妥的是secrets.token_bytes(32)+ base64url编码 - 计算
code_challenge时，必须用S256哈希（SHA-256），不能用plain——后者已被主流平台（Google、Apple、Microsoft）拒绝 - 哈希后要再做base64url编码：先
hashlib.sha256(code_verifier.encode()).digest()，再base64.urlsafe_b64encode(...).decode().replace("=", "")
请求授权页时如何正确传参
移动端通常用系统浏览器或WebView打开授权URL，参数必须拼在query string里，且code_challenge和code_challenge_method是必需字段。
立即学习“Python免费学习笔记（深入）”；
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
示例URL构造逻辑：
import secrets
import hashlib
import base64
code_verifier = secrets.token_urlsafe(32)
code_challenge = base64.urlsafe_b64encode(
hashlib.sha256(code_verifier.encode()).digest()
).decode().replace("=", "")
auth_url = (
"https://auth.example.com/authorize?"
f"response_type=code"
f"&client_id=my-mobile-app"
f"&redirect_uri=https%3A%2F%2Fmyapp.com%2Fcallback"
f"&code_challenge={code_challenge}"
f"&code_challenge_method=S256"
f"&scope=openid%20profile%20email"
)
注意：redirect_uri必须和注册时完全一致（包括末尾斜杠），否则授权服务器会拒绝；scope中若含offline_access，还要确认该平台是否支持刷新令牌（有些仅对Web客户端开放）。
换token时必须带上原始code_verifier
拿到authorization_code后，向/token端点发起POST请求，此时code_verifier是唯一能证明“这次请求来自当初发起授权的那个客户端”的凭证。
- 请求头必须是
Content-Type: application/x-www-form-urlencoded - Body里除了
code、redirect_uri、client_id，一定要有code_verifier字段——漏掉它，服务端返回invalid_grant错误 - 不要试图在Header里加
Authorization: Basic ...——移动端没有client_secret，也不该传
典型错误响应：{"error":"invalid_grant","error_description":"PKCE code verifier does not match"}，基本就是code_verifier没传、传错、或和服务端算出的code_challenge不匹配。
整个流程里最易忽略的细节是：code_verifier必须在内存中安全保管，直到换token完成，不能写入日志、本地文件或明文存储到Keychain/Keystore以外的地方——它本身就是短期敏感凭据。
