PKCE 是纯前端应用 OAuth 登录的唯一可行安全路径，需用 crypto.getRandomValues() 生成 ≥32 字节 code_verifier，经 SHA-256 + Base64URL 编码得 code_challenge，授权请求须携带二者及 S256 方法，token 交换时传原始 verifier 且禁用 client_secret。
纯前端 HTML 应用（如 SPA、桌面 Electron App、PWA）做 OAuth 登录时，client_secret 不能暴露在代码里，传统授权码流程直接退化为不安全的隐式模式。PKCE 不是“可选增强”，而是唯一可行的安全路径——它让 HTML 页面能在不依赖后端代理 token 交换的前提下，合法、合规地完成授权。
生成 code_verifier 和 code_challenge 必须用加密安全随机源
浏览器环境没有 /dev/urandom，但有 crypto.getRandomValues()。手写 Base64URL 编码时容易漏掉 URL 安全性处理（比如把 + 和 / 换成 - 和 _，去掉末尾 =）。
- 别用
Math.random()——熵值不足，攻击者可暴力穷举 -
code_verifier长度必须 ≥32 字符；推荐生成 32 字节再编码，结果约 43 字符 - 哈希必须用
S256（SHA-256 + Base64URL），禁用plain模式；OAuth 服务器若只支持plain，说明它已过时且不合规 - 示例关键片段：
function generateCodeVerifier() { const array = new Uint8Array(32); crypto.getRandomValues(array); return btoa(String.fromCharCode(...array)) .replace(/\+/g, '-').replace(/\//g, '_').replace(/=/g, ''); }
/authorize 请求必须带上 code_challenge 和 code_challenge_method
很多前端开发者只加了 code_challenge，却漏掉 code_challenge_method=S256，导致授权服务器按默认 plain 处理，后续校验失败。
- 完整参数至少包括：
response_type=code、client_id、redirect_uri、scope、state、code_challenge、code_challenge_method=S256 -
state仍需保留（防 CSRF），不能因为用了 PKCE 就省略 - 跳转必须用
window.location.href或location.assign()，不能用fetch或XMLHttpRequest发起 —— 否则无法触发浏览器重定向和 OAuth 服务器的 session 绑定
/token 请求必须用 POST 且携带原始 code_verifier
拿到 code 后，前端要发起 HTTPS POST 到 token 端点。这里最容易出错的是：把 code_verifier 放在 URL 查询参数里（明文泄露）、或误传成 code_challenge。
从零开始创建惊艳、动画丰富且自包含的 HTML 演示文稿，或通过转换 PowerPoint 文件生成。当用户希望制作幻灯片、构建演示文稿、打造路演资料（pitch deck）、将 PPT/PPTX 转换为网页格式，或增强现有 HTML 演示文稿时，应使用此能力。该能力帮助用户通过视觉预览而非抽象选项来发掘自身审美偏好。
立即学习“前端免费学习笔记（深入）”；
- 请求体必须是
application/x-www-form-urlencoded，字段包括：grant_type=authorization_code、code、redirect_uri、client_id、code_verifier - 不要传
client_secret—— PKCE 场景下它本就不该存在；如果服务器报invalid_client，大概率是服务端配置没关掉 client_secret 强制校验 - 错误响应常见：
{"error":"invalid_grant","error_description":"code verifier does not match"}→ 检查哈希是否用了 S256、Base64URL 编码是否一致、code_verifier是否和生成时完全相同（含空格/换行）
Swagger UI、Cognito、Auth0 等平台启用 PKCE 的配置陷阱
即使平台声称支持 PKCE，实际启用仍需手动开关。例如 Swagger UI 默认关闭 PKCE，Auth0 的 SPA 应用类型默认不启用 S256。
- Swagger UI：必须显式设置
usePkceWithAuthorizationCodeGrant: true，否则initOAuth会走传统流程 - AWS Cognito：在 App Client 设置中勾选 “Generate secret” 必须为 ❌，并确认 “Allowed OAuth Flows” 包含
code grant，“Allowed OAuth Scopes” 已配好，且 “Authentication Flow” 设为ALLOW_CUSTOM_AUTH或兼容 PKCE 的选项 - Auth0：App Type 选 “Single Page Web Applications”，并在 Advanced Settings → Grant Types 中启用
Authorization Code和PKCE - 本地调试时，Chrome 的
chrome://flags/#unsafely-treat-insecure-origin-as-secure可临时允许http://localhost使用cryptoAPI，但上线必须用 HTTPS
PKCE 的核心约束很朴素：code_verifier 只能用一次、不能持久化存储、不能跨会话复用。很多团队把它做成全局单例或 localStorage 缓存，结果导致并发授权失败或重放漏洞。真正安全的实现，是每次登录流程都重新生成一对值，并在换取 token 后立即丢弃 —— 这个“一次性”才是它防中间人劫持的物理基础。
