addopenidconnect报invalid_client错误，根本原因是客户端认证方式不匹配：默认仅支持client_secret_post，若idp要求client_secret_basic，须显式设置options.tokenendpointauthenticationmethod = openidconnecttokenendpointauthenticationmethod.basic。
OpenID Connect 在 C# 中不是“配好就能用”的黑盒，关键配置项一旦错位，invalid_client、400 Bad Request 或静默重定向失败是常态，而不是例外。
为什么 AddOpenIdConnect 启动就报 invalid_client？
这几乎总是客户端认证方式不匹配导致的。OIDC 规范定义了多种 token_endpoint_auth_methods_supported（如 client_secret_basic、client_secret_post），但 ASP.NET Core 的 Microsoft.AspNetCore.Authentication.OpenIdConnect 默认只启用 client_secret_post —— 即把 client_id 和 client_secret 作为表单字段 POST 到 Token 端点。
如果你的 IdP（比如某些定制化部署的 Keycloak、自建 IdentityServer 或 OneLogin 旧配置）明确要求 client_secret_basic（即 HTTP Basic Auth 头），而你没显式指定，就会触发 invalid_client。
解决方法是手动设置 TokenEndpointAuthenticationMethod：
options.TokenEndpointAuthenticationMethod = OpenIdConnectTokenEndpointAuthenticationMethod.Basic;
可选值包括：
-
OpenIdConnectTokenEndpointAuthenticationMethod.Post（默认） OpenIdConnectTokenEndpointAuthenticationMethod.BasicOpenIdConnectTokenEndpointAuthenticationMethod.ClientSecretJwt
注意：Basic 模式下，client_secret 会以 Base64 编码后放入 Authorization: Basic <encoded></encoded> 请求头；Post 模式则走 application/x-www-form-urlencoded body。
ResponseType = "code" 和 "code id_token" 的实际区别
绝大多数生产场景必须用 ResponseType = "code"（授权码模式）。它走完整三步：重定向 → 用户登录 → 换 Token。安全，支持 PKCE，且 id_token 可被后端验证，避免前端 JS 直接触碰敏感 token。
"code id_token" 是混合模式，会同时返回授权码和 ID Token（在重定向 URI 的 fragment 中）。它的问题很实在：
- ID Token 明文暴露在浏览器地址栏，可能被历史记录、代理、日志截获
- 无法做服务端 token introspection 或 revocation
-
SaveTokens = true时，ASP.NET Core 会尝试从 fragment 提取，但现代浏览器对 fragment 的读取受同源策略限制，常失败
除非你在做纯前端 SPA + oidc-client.js，否则别碰混合模式。坚持用 code，并确保 ResponseMode = OpenIdConnectResponseMode.Query（避免 fragment 解析问题）。
GetClaimsFromUserInfoEndpoint = true 不是万能补丁
这个开关控制是否在拿到 Access Token 后，主动调用 IdP 的 /userinfo 端点拉取用户信息（比如 email、given_name）。但它依赖三个前提：
- IdP 实际实现了
/userinfo端点（不是所有都支持，尤其私有 IdP） - Access Token 有足够 scope（如
openid profile email），否则401 Unauthorized - 网络可达且未被防火墙拦截（开发机连内网 IdP 常因 DNS 或代理失败）
如果启用了却没拿到预期 claim，先检查 HttpContext.User.Claims 是否含 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name 这类原始 claim；再确认 IdP 的 .well-known/openid-configuration 中 userinfo_endpoint 字段是否非空。不要盲目依赖它填满所有字段 —— 更可靠的做法是在 OnUserInformationReceived 事件里手动补全或映射。
为什么 OnRedirectToIdentityProvider 里改 audience 没生效？
因为 audience 是 OIDC 标准参数，但不同 IdP 对它的处理逻辑差异极大：
- Azure AD / Entra ID：认
resource参数，audience被忽略 - Auth0：认
audience，但必须在 client 配置中提前白名单允许 - Keycloak：需开启
Client Authenticator并配置Valid Redirect URIs，否则直接拒掉带audience的请求
正确做法不是硬塞参数，而是查 IdP 文档确认它期望的资源标识符字段名，并在 OnRedirectToIdentityProvider 中用对应 key 设置：
context.ProtocolMessage.SetParameter("resource", "https://api.example.com"); // Azure AD
context.ProtocolMessage.SetParameter("audience", "https://api.example.com"); // Auth0
更稳妥的方式是把资源标识符写进 client 的 scope（如 options.Scope.Add("api://myapp")），由 IdP 自动解析 —— 这比手动塞参数兼容性高得多。
OIDC 集成最耗时的部分从来不是写代码，而是反复比对 IdP 的元数据、日志和实际 HTTP 流量。建议开 Fiddler 或 Edge DevTools 的 Network 面板，盯住 /authorize 和 /token 两个请求的完整 URL、Headers 和 Body —— 错误往往藏在 Authorization 头格式、Content-Type 类型、甚至 query string 的编码细节里。
