OpenID Connect需用libcurl发x-www-form-urlencoded请求、OpenSSL/libsodium验JWT签名、严格校验exp/iat/nbf时间戳及iss/aud字段，C++标准库无内置支持。
OpenID Connect不是C++标准库能直接调用的协议
OpenID Connect本质是基于HTTPS的REST+JWT协议栈，C++没有内置支持——你得自己拼HTTP请求、解析JSON、校验JWT签名。别找std::openid_connect，它不存在。
常见错误现象：400 Bad Request（参数拼错）、401 Unauthorized（JWT过期或签名验不过）、invalid_token（没验iss/aud字段）。这些都不是C++语法问题，而是协议理解偏差。
- 必须用HTTP客户端库（如
libcurl）发POST /token、GET /userinfo - JWT解析不能只用
jsoncpp读payload——签名必须用公钥验，否则alg=none攻击就中招 -
id_token里的exp和iat要转成std::time_t比对，别直接当字符串用
JWT签名验证必须用OpenSSL或libsodium，不能手撕
很多人以为Base64解码Header+Payload再拼签名就能验，漏了关键一步：RSA/ECDSA签名算法依赖密钥和哈希方式（RS256≠ES256），不调用密码学库会直接失败。
使用场景：拿到id_token后，必须验证签名有效性+字段合法性，否则用户身份不可信。
立即学习“C++免费学习笔记（深入）”；
- 从OIDC Provider的
/.well-known/openid-configuration取jwks_uri，再GET拿到keys数组 - 用
openssl_pkey_get_public()或sodium_crypto_sign_verify_detached()验签名，别自己实现PKCS#1 v1.5填充 - 检查
kid头字段匹配JWKS里哪个key，不匹配就换下一个key重试
libcurl发token请求时，Content-Type和body格式极易出错
OIDC的/token端点严格要求application/x-www-form-urlencoded，不是JSON。用jsoncpp序列化然后设Content-Type: application/json必挂。
错误现象：{"error":"invalid_request","error_description":"Unsupported grant type"}——其实是因为服务端根本没解析到grant_type参数。
- 用
curl_easy_setopt(curl, CURLOPT_POSTFIELDS, "grant_type=authorization_code&code=xxx&redirect_uri=xxx&client_id=xxx&client_secret=xxx") - 必须设
curl_easy_setopt(curl, CURLOPT_HTTPHEADER, headers)，其中headers含"Content-Type: application/x-www-form-urlencoded" -
client_secret若含特殊字符（如+、/），要URL encode，别直接塞进POST body
std::chrono处理JWT时间戳容易忽略时区和精度
JWT的exp、iat、nbf都是秒级UNIX时间戳（UTC），但std::chrono::system_clock::now()返回的是纳秒级，直接减会溢出或比较失效。
性能影响：每次验token都做一次duration_cast<:chrono::seconds>()</:chrono::seconds>开销极小，但漏掉它会导致永远认为token已过期。
- 用
auto now = std::chrono::duration_cast<:chrono::seconds>(std::chrono::system_clock::now().time_since_epoch()).count()</:chrono::seconds> - 检查
exp > now且iat ，<code>nbf存在时也要now >= nbf - 别用
localtime()或strftime()去“看”时间值——那只是调试干扰项
最麻烦的不是写代码，是Provider返回的id_token可能用RS384而你的OpenSSL没编译对应算法，或者JWKS的keys里混着RSA和EC两种类型却只试第一个。协议细节藏在RFC 7519和OIDC Core里，不是靠搜“C++ JWT example”能绕过去的。
