推荐使用openssl 1.1.1+（支持sha256、hmac-sha256和base64url）或cpp-jwt（轻量但功能有限），避免crypto++（其base64url缺失填充处理导致校验失败）。
PKCE流程里C++该用什么库做加密和编码
纯C++标准库不支持PKCE必需的SHA256、HMAC-SHA256、base64url（注意不是普通base64），得靠第三方。推荐openssl（1.1.1+）或cpp-jwt（轻量但只覆盖部分），别用crypto++——它的base64url实现缺填充处理，会导致code_verifier校验失败。
关键点：PKCE要求code_challenge用S256方式生成，即先对code_verifier做SHA256哈希，再base64url编码。漏掉url-safe替换（+→-、/→_、去掉=）是高频错误。
-
code_verifier必须是32字节以上随机字符串（推荐43字节base64url编码后的长度），用RAND_bytes()或std::random_device生成 -
code_challenge不能直接对原始字符串哈希——必须先SHA256(code_verifier)，再base64url编码结果 - 移动端嵌入WebView时，确保
code_verifier不被日志打印或内存dump泄露
如何安全地在C++客户端保存和传递PKCE参数
C++没有类似Android SharedPreferences或iOS Keychain的跨平台安全存储，code_verifier绝不能明文存文件或std::string变量中。常见错误是把code_verifier存在全局变量里，结果被core dump抓取。
可行方案只有两个：一是用平台原生API封装（Android调AndroidKeyStore，iOS走SecItemAdd），二是用libsodium做内存加密（sodium_memzero()清零+sodium_mlock()锁内存）。别信“用const char*就安全”这种说法——编译器可能把它放进.rodata段。
立即学习“C++免费学习笔记（深入）”；
- 每次认证流程开始前生成新
code_verifier，用完立刻sodium_memzero()清零 -
code_challenge和code_challenge_method=S256可公开传输，但必须和state参数一起签名防篡改 - WebView跳转URL里带
code_challenge时，确保URL未被代理或调试工具截获（尤其开发环境）
WebView集成OAuth2重定向时C++怎么捕获code和state
C++本身不解析HTTP重定向，得靠WebView控件暴露事件。Qt WebEngine用QWebEngineUrlRequestInterceptor拦截http://localhost/callback?code=xxx&state=yyy；Android JNI需在shouldOverrideUrlLoading里匹配回调地址；iOS用WKNavigationDelegate的decidePolicyFor。核心是：别等页面加载完成再取URL——重定向瞬间就结束了，要监听URL变更事件。
容易踩的坑：state参数必须和服务端下发的一致，且需在C++侧校验（防止CSRF）。如果用http://localhost作为redirect_uri，确保本地HTTP服务没被其他App占用（Android上常被Chrome抢端口）。
- 重定向URL里的
code是一次性凭证，获取后立即用于换token，不可缓存 -
state建议用crypto_randbytes()生成32字节随机值，Base64url编码后传给服务端 - 不要在WebView里执行
location.href跳转——会丢失code_verifier上下文
换token阶段C++发POST请求要注意哪些坑
PKCE最终一步是用code、code_verifier、client_id向/token端点发POST。错误集中在Content-Type和参数格式：必须用application/x-www-form-urlencoded，且所有参数（包括code_verifier）要URL编码——漏掉code_verifier的%编码会导致400错误。
另一个坑是SSL证书验证：移动端常禁用证书校验来绕过测试环境问题，但PKCE本意就是防中间人，关了验证等于白做。用libcurl时务必设CURLOPT_SSL_VERIFYPEER为1，并配好CA bundle路径。
- POST body示例：
grant_type=authorization_code&code=xxx&redirect_uri=http%3A%2F%2Flocalhost%2Fcallback&client_id=abc&code_verifier=def - 响应里的
access_token建议用sodium_mlock()锁定内存，避免被内存扫描工具读取 - 别把
refresh_token存明文文件——移动端应交由系统密钥库管理
PKCE不是加个参数就安全了，code_verifier生命周期管理、内存防护、重定向拦截时机，这三个地方出问题，整个流程就形同虚设。
