Apereo CAS 的 OIDC Discovery 实战.well-known 端点、响应字段与 cas.authn.oidc.discovery 配置全解【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址: https://gitcode.com/gh_mirrors/ca/casApereo CAS 内置的 OIDC Discovery 服务让客户端只需知道 issuer就能通过.well-known端点一次性拿到授权、令牌、用户信息、JWKS 等全部端点地址和算法能力清单。本文带你走读 CAS 的三个 well-known 端点含 WebFinger、Discovery 响应 JSON 的逐字段含义以及cas.authn.oidc.discovery.*配置键的默认值与定制方法读完后你无需翻源码即可独立完成部署验证与元数据定制。从一个真实请求开始CAS 暴露了哪三个 well-known 端点假设客户端手里只有 issuerhttps://sso.example.org/cas/oidc它下一步该做什么答案是向 CAS 要一份能力说明书。CAS 把 Discovery 相关的路由全部收敛在 OidcWellKnownEndpointController.java 中路径常量定义见 OidcConstants.java路由以默认上下文/cas为例媒体类型作用/cas/oidc/.well-knownapplication/json兼容早期约定的裸端点响应与下面一行完全一致/cas/oidc/.well-known/openid-configurationapplication/json标准 OIDC Discovery 文档/cas/oidc/.well-known/oauth-authorization-serverapplication/jsonRFC 8414 风格的 OAuth 授权服务器元数据内容同上/cas/oidc/.well-known/webfingerapplication/jrdjsonWebFinger从账号标识反查 issuer两个要点openid-configuration和oauth-authorization-server由控制器中的同一个方法处理输出字节级一致区别只在入口 URL路由声明里还带了/**/前缀的变体意味着上下文路径不是/cas的部署同样可用。issuer 校验为什么换个域名访问就只剩 404CAS 在吐出任何元数据之前会做一道拦截OidcWellKnownEndpointController先调用父类 BaseOidcController.java 的isIssuerValidForEndpoint后者把请求交给OidcIssuerService.validateIssuer比对请求 Host 与配置的 issuer。比对失败不会返回 200 加错误体而是直接404 Not Found——元数据本身不泄漏未注册的域名上什么都没有。仓库里的行为基准见 OidcWellKnownEndpointControllerTests.javaverifyUnknownIssuer用未注册的sso2.example.org作为 ServerName 发起请求断言结果必须是status().isNotFound()verifyWellKnownOpenIdConfiguration则断言正常访问时$.issuer存在。多域名 / 通配符 issuer 场景下如果你发现某些 Host 访问 well-known 得到 404第一排查对象就是 issuer 配置而非网络。响应 JSON 逐字段拆解Discovery 文档的载体是 OidcServerDiscoverySettings.java每个字段都用JsonProperty固定了 JSON 名称。端点类字段不是存储值而是 getter 里用issuer / 路径段现拼的所以改 issuer 后所有端点自动跟随。端点类字段随 issuer 动态拼接JSON 字段拼接结果指向的能力authorization_endpoint{issuer}/oidcAuthorize授权码 / 隐式流程入口token_endpoint{issuer}/oidcAccessToken令牌颁发device_authorization_endpoint与token_endpoint相同设备授权设备码在令牌端点兑换userinfo_endpoint{issuer}/oidcProfile用户信息jwks_uri{issuer}/jwks校验 ID Token / 签名令牌的公钥集registration_endpoint{issuer}/register动态客户端注册client_registration_types_supported固定为[automatic]end_session_endpoint{issuer}/oidcLogout单点登出introspection_endpoint{issuer}/introspect令牌自省revocation_endpoint{issuer}/revoke令牌吊销pushed_authorization_request_endpoint{issuer}/oidcPushAuthorizePAR 推送授权请求backchannel_authentication_endpoint{issuer}/oidcCibaCIBA 后信道认证能力声明类字段来自配置下一节详述scopes_supported、claims_supported、subject_types_supported默认public、pairwise、claim_types_supported默认normalgrant_types_supported默认覆盖 authorization_code、password、client_credentials、refresh_token、CIBA、pre-authorized_code、jwt-bearer、token-exchange、device_code、uma-ticket 共 10 种、response_types_supportedcode, token, id_token, id_token token, device_code、response_modes_supportedquery, fragment, form_post及对应.jwt变体token_endpoint_auth_methods_supported默认client_secret_basic, client_secret_post, client_secret_jwt, private_key_jwt, tls_client_auth, none配套字段token_endpoint_auth_signing_alg_values_supported默认覆盖 RS/PS/ES/HS 各系列算法按 RFC 8414 要求不出现noneid_token_*、userinfo_*、introspection_*、request_object_*、backchannel_authentication_request_signing_alg_values_supported等签名/加密算法清单以及code_challenge_methods_supportedplain, S256、prompt_values_supportednone, login, consent布尔开关claims_parameter_supported、request_parameter_supported、request_uri_parameter_supported三者默认true、native_sso_supported默认true、require_pushed_authorization_requests默认false派生字段backchannel_logout_supported/frontchannel_logout_supported连同同名*_session_supported字段取自cas.authn.oidc.logout配置而非 discovery 前缀pre-authorized_grant_anonymous_access_supported在grant_types_supported含 pre-authorized_code 时恒为true配置项怎么分生产环境常改的 vs 了解默认值即可的全部键挂在cas.authn.oidc.discovery下模型类是 OidcDiscoveryProperties.java嵌套于 OidcProperties.java 的discovery字段。按要不要动手而不是按类型分组生产环境可能实际改动的配置键默认值典型动机scopesopenid, profile, email, address, phone, offline_access, device_sso, client_configuration_scope, uma_authorization, uma_protection, client_registration_scope收敛暴露面只留业务需要的 scopeclaimssub, acr, name, preferred_username, family_name, given_name, middle_name, profile, picture, nickname, website, zoneinfo, locale, updated_at, birthdate, email, email_verified, phone_number, phone_number_verified, address, gender与隐私合规对齐裁掉用不到的声明id-token-signing-alg-values-supportednone, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512, HS256, HS384, HS512去掉none收紧到实际使用的 2~3 个算法token-endpoint-auth-methods-supportedclient_secret_basic, client_secret_post, client_secret_jwt, private_key_jwt, tls_client_auth, none面向公共客户端时保留none否则裁掉response-types-supported/response-modes-supported见上文能力声明清单与真实流量中的 grant 流程对齐code-challenge-methods-supportedplain, S256生产建议只留S256verified-claims-supported及 Identity Assurance 集合trust-frameworks-supported、evidence-supported、documents-supported、documents-validation-methods-supported、documents-verification-methods-supported、electronic-records-supported、claims-in-verified-claims-supportedtrue各集合默认空接入 OIDC Identity Assurance 扩展时按需填充了解默认值即可、很少动的参数开关claims-parameter-supported、request-parameter-supported、request-uri-parameter-supported默认trueauthorization-response-issuer-parameter-supported、tls-client-certificate-bound-access-tokens、require-pushed-authorization-requests、backchannel-user-code-parameter-supported默认falsenative-sso-supported默认trueCIBA 传输backchannel-token-delivery-modes-supported默认poll, ping, push算法清单dpop-signing-alg-values-supportedRS256/384/512, ES256/384/512、id-token-encryption-alg-values-supportedRSA1_5, RSA-OAEP, RSA-OAEP-256, A128KW … ECDH-ESA256KW等 13 种、对应的*_encryption_encoding_values_supportedA128CBC-HS256 … A256GCM6 种以及 userinfo / introspection / request-object 的同类字段——它们的默认值就是全量声明只有做算法白名单收敛时才需要逐一覆写acr-values-supported默认空列表但别急着填——见下一节 YAML 中所有键用 kebab-case 书写如claims-parameter-supported数组可用逗号分隔字符串或标准 YAML 列表。特殊行为acr_values_supported 会自动汇总已启用的 MFA这是整份配置里唯一一处不填比填更有用的逻辑实现在 OidcServerDiscoverySettingsFactory.java 的populateDiscovery中当acrValuesSupported为空时CAS 遍历应用上下文里全部MultifactorAuthenticationProvider把每个 Provider 的getId()收进acr_values_supported。为什么这么设计ACR认证上下文类是 MFA 能力在 OIDC 侧的映射手工维护容易与启用的 MFA 模块漂移——启用 Duo 忘了加 ACR 值客户端就不会用它发起 MFA。工厂自动推导后启用的 MFA 集合永远与元数据一致测试OidcServerDiscoverySettingsFactoryTests位于 support/cas-server-support-oidc/src/test/也断言了未显式配置时getAcrValuesSupported()非空。同一工厂还有几处配置没写、响应里却会出现的内容排查响应差异时别漏看scopes 是并集resolveScopesSupported会把cas.authn.oidc.vc.issuer.credential-configurations中每个可验证凭据配置的scope追加进scopes_supported去重后用于 OpenID4VCI 的凭据请求client attestation配置了 trust anchors 时自动追加attest_jwt_client_auth、attest_jwt_client_auth_dpop两种认证方法challenge 功能开启时再追加challenge_endpointVC 状态列表cas.authn.oidc.vc.issuer.status-list启用后追加status_list_aggregation_endpoint登出能力backchannel_logout_supported/frontchannel_logout_supported读取cas.authn.oidc.logout.backchannel-logout-supported/frontchannel-logout-supported均默认trueWebFinger用一个账号标识反查 issuer标准 Discovery 要求客户端先知道 issuerWebFinger 解决反向问题——只知道用户是谁如acct:casusersso.example.org问出他属于哪个 Provider。端点为/{context}/oidc/.well-known/webfinger响应类型application/jrdjson参数如下参数必填说明resource是资源标识典型值acct:userhost缺失时返回400 Bad Requestrel否关系类型标准值为http://openid.net/specs/connect/1.0/issuer常量WEBFINGER_REL命中时响应体形如{ subject: acct:casusersso.example.org, links: [ { rel: http://openid.net/specs/connect/1.0/issuer, href: https://sso.example.org/cas/oidc } ] }默认实现 OidcDefaultWebFingerDiscoveryService.java 的判定顺序值得知道它决定了什么请求会拿到 404resource与 issuer 完全一致忽略大小写→ 直接返回否则按resourcePattern正则cas.authn.oidc.webfinger.resource-pattern可覆盖归一化scheme 必须是acct用userinfo仓库先按邮箱findByEmailAddress、再按用户名findByUsername查找查无此人 → 404resource 的 host 与 issuer 的 host 不一致 → 404。userinfo仓库支持默认实现之外再接 Groovy 脚本或 REST 接口配置模型 OidcWebFingerProperties.javacas.authn.oidc.webfinger.enabled默认true。行为基准见 OidcWebFingerUserInfoRepositoryTests.java 与 OidcDefaultWebFingerDiscoveryServiceTests.java带rel与不带rel均返回 200缺resource返回 400。用 curl 验证三个端点并定制元数据部署完成后三条命令覆盖全部入口把域名换成你的部署# 标准 OIDC Discovery 文档 curl -s https://sso.example.org/cas/oidc/.well-known/openid-configuration # 裸 .well-known 端点输出应与上者一致 curl -s https://sso.example.org/cas/oidc/.well-known # WebFinger用账号反查 issuer curl -s https://sso.example.org/cas/oidc/.well-known/webfinger?resourceacct:casusersso.example.orgrelhttp://openid.net/specs/connect/1.0/issuer验收标准issuer、authorization_endpoint、token_endpoint、jwks_uri、scopes_supported、claims_supported均存在且端点前缀与 issuer 一致用未注册域名替换 Host 再请求应得到 404。一段可直接使用的定制示例收敛 scope/claim、收紧算法、开启 Identity Assurancecas: authn: oidc: issuer: https://sso.example.org/cas/oidc discovery: scopes: openid,profile,email,phone,offline_access claims: sub,name,email,email_verified,preferred_username response-types-supported: code response-modes-supported: query,fragment,form_post code-challenge-methods-supported: S256 id-token-signing-alg-values-supported: RS256,ES256 token-endpoint-auth-methods-supported: client_secret_basic,client_secret_post prompt-values-supported: none,login,consent verified-claims-supported: true trust-frameworks-supported: trust_framework_example改完任何cas.authn.oidc.discovery.*键后无需改代码重启或经配置刷新即在新响应中生效元数据由oidcServerDiscoverySettingsFactory以单例装配控制器直接返回该对象序列化结果。官方文档对应 OIDC-Authentication-Discovery.md其余 OIDC 能力配置参见 docs/cas-server-documentation/authentication/ 目录。常见误区与上线前检查清单误区一改了 issuerwell-known 打不开。多半不是端点坏了而是 issuer 校验按 Host 比对DNS/负载均衡上多挂的域名没有包含进 issuer 配置。先核对 issuer再看日志中 issuer for endpoint(s) ... is invalid 的告警。误区二手动往acr-values-supported里加 MFA 名称。留空即可工厂会自动汇总已注册的MultifactorAuthenticationProvider只有想手工收窄 ACR 集合时才显式赋值。误区三以为oauth-authorization-server是另一份元数据。它与openid-configuration同方法同响应只是给 RFC 8414 客户端的入口。误区四把token-endpoint-auth-methods里的none当成漏洞。它是无凭据客户端也可访问令牌端点的能力声明如钱包兑换 pre-authorized code是否保留取决于你的客户端形态。上线前清单三个端点各 curl 一次确认 200 关键字段或 WebFinger 的 400/404 负向路径也测过scopes_supported、claims_supported、签名算法清单与合规基线一致none类宽松项已按环境裁剪jwks_uri实际可达且公钥能解验 ID Token未注册域名访问 well-known 稳定返回 404无元数据泄漏启用的 MFA 模块与acr_values_supported输出一致自动推导场景下应自动吻合。【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址: https://gitcode.com/gh_mirrors/ca/cas创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/11/5 5:21:48 · 阅读 1.2k Apereo CAS 的 OIDC Discovery 实战：.well-known 端点、响应字段与 cas.authn.oidc.discovery 配置全解
Apereo CAS 的 OIDC Discovery 实战.well-known 端点、响应字段与 cas.authn.oidc.discovery 配置全解【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址: https://gitcode.com/gh_mirrors/ca/casApereo CAS 内置的 OIDC Discovery 服务让客户端只需知道 issuer就能通过.well-known端点一次性拿到授权、令牌、用户信息、JWKS 等全部端点地址和算法能力清单。本文带你走读 CAS 的三个 well-known 端点含 WebFinger、Discovery 响应 JSON 的逐字段含义以及cas.authn.oidc.discovery.*配置键的默认值与定制方法读完后你无需翻源码即可独立完成部署验证与元数据定制。从一个真实请求开始CAS 暴露了哪三个 well-known 端点假设客户端手里只有 issuerhttps://sso.example.org/cas/oidc它下一步该做什么答案是向 CAS 要一份能力说明书。CAS 把 Discovery 相关的路由全部收敛在 OidcWellKnownEndpointController.java 中路径常量定义见 OidcConstants.java路由以默认上下文/cas为例媒体类型作用/cas/oidc/.well-knownapplication/json兼容早期约定的裸端点响应与下面一行完全一致/cas/oidc/.well-known/openid-configurationapplication/json标准 OIDC Discovery 文档/cas/oidc/.well-known/oauth-authorization-serverapplication/jsonRFC 8414 风格的 OAuth 授权服务器元数据内容同上/cas/oidc/.well-known/webfingerapplication/jrdjsonWebFinger从账号标识反查 issuer两个要点openid-configuration和oauth-authorization-server由控制器中的同一个方法处理输出字节级一致区别只在入口 URL路由声明里还带了/**/前缀的变体意味着上下文路径不是/cas的部署同样可用。issuer 校验为什么换个域名访问就只剩 404CAS 在吐出任何元数据之前会做一道拦截OidcWellKnownEndpointController先调用父类 BaseOidcController.java 的isIssuerValidForEndpoint后者把请求交给OidcIssuerService.validateIssuer比对请求 Host 与配置的 issuer。比对失败不会返回 200 加错误体而是直接404 Not Found——元数据本身不泄漏未注册的域名上什么都没有。仓库里的行为基准见 OidcWellKnownEndpointControllerTests.javaverifyUnknownIssuer用未注册的sso2.example.org作为 ServerName 发起请求断言结果必须是status().isNotFound()verifyWellKnownOpenIdConfiguration则断言正常访问时$.issuer存在。多域名 / 通配符 issuer 场景下如果你发现某些 Host 访问 well-known 得到 404第一排查对象就是 issuer 配置而非网络。响应 JSON 逐字段拆解Discovery 文档的载体是 OidcServerDiscoverySettings.java每个字段都用JsonProperty固定了 JSON 名称。端点类字段不是存储值而是 getter 里用issuer / 路径段现拼的所以改 issuer 后所有端点自动跟随。端点类字段随 issuer 动态拼接JSON 字段拼接结果指向的能力authorization_endpoint{issuer}/oidcAuthorize授权码 / 隐式流程入口token_endpoint{issuer}/oidcAccessToken令牌颁发device_authorization_endpoint与token_endpoint相同设备授权设备码在令牌端点兑换userinfo_endpoint{issuer}/oidcProfile用户信息jwks_uri{issuer}/jwks校验 ID Token / 签名令牌的公钥集registration_endpoint{issuer}/register动态客户端注册client_registration_types_supported固定为[automatic]end_session_endpoint{issuer}/oidcLogout单点登出introspection_endpoint{issuer}/introspect令牌自省revocation_endpoint{issuer}/revoke令牌吊销pushed_authorization_request_endpoint{issuer}/oidcPushAuthorizePAR 推送授权请求backchannel_authentication_endpoint{issuer}/oidcCibaCIBA 后信道认证能力声明类字段来自配置下一节详述scopes_supported、claims_supported、subject_types_supported默认public、pairwise、claim_types_supported默认normalgrant_types_supported默认覆盖 authorization_code、password、client_credentials、refresh_token、CIBA、pre-authorized_code、jwt-bearer、token-exchange、device_code、uma-ticket 共 10 种、response_types_supportedcode, token, id_token, id_token token, device_code、response_modes_supportedquery, fragment, form_post及对应.jwt变体token_endpoint_auth_methods_supported默认client_secret_basic, client_secret_post, client_secret_jwt, private_key_jwt, tls_client_auth, none配套字段token_endpoint_auth_signing_alg_values_supported默认覆盖 RS/PS/ES/HS 各系列算法按 RFC 8414 要求不出现noneid_token_*、userinfo_*、introspection_*、request_object_*、backchannel_authentication_request_signing_alg_values_supported等签名/加密算法清单以及code_challenge_methods_supportedplain, S256、prompt_values_supportednone, login, consent布尔开关claims_parameter_supported、request_parameter_supported、request_uri_parameter_supported三者默认true、native_sso_supported默认true、require_pushed_authorization_requests默认false派生字段backchannel_logout_supported/frontchannel_logout_supported连同同名*_session_supported字段取自cas.authn.oidc.logout配置而非 discovery 前缀pre-authorized_grant_anonymous_access_supported在grant_types_supported含 pre-authorized_code 时恒为true配置项怎么分生产环境常改的 vs 了解默认值即可的全部键挂在cas.authn.oidc.discovery下模型类是 OidcDiscoveryProperties.java嵌套于 OidcProperties.java 的discovery字段。按要不要动手而不是按类型分组生产环境可能实际改动的配置键默认值典型动机scopesopenid, profile, email, address, phone, offline_access, device_sso, client_configuration_scope, uma_authorization, uma_protection, client_registration_scope收敛暴露面只留业务需要的 scopeclaimssub, acr, name, preferred_username, family_name, given_name, middle_name, profile, picture, nickname, website, zoneinfo, locale, updated_at, birthdate, email, email_verified, phone_number, phone_number_verified, address, gender与隐私合规对齐裁掉用不到的声明id-token-signing-alg-values-supportednone, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512, HS256, HS384, HS512去掉none收紧到实际使用的 2~3 个算法token-endpoint-auth-methods-supportedclient_secret_basic, client_secret_post, client_secret_jwt, private_key_jwt, tls_client_auth, none面向公共客户端时保留none否则裁掉response-types-supported/response-modes-supported见上文能力声明清单与真实流量中的 grant 流程对齐code-challenge-methods-supportedplain, S256生产建议只留S256verified-claims-supported及 Identity Assurance 集合trust-frameworks-supported、evidence-supported、documents-supported、documents-validation-methods-supported、documents-verification-methods-supported、electronic-records-supported、claims-in-verified-claims-supportedtrue各集合默认空接入 OIDC Identity Assurance 扩展时按需填充了解默认值即可、很少动的参数开关claims-parameter-supported、request-parameter-supported、request-uri-parameter-supported默认trueauthorization-response-issuer-parameter-supported、tls-client-certificate-bound-access-tokens、require-pushed-authorization-requests、backchannel-user-code-parameter-supported默认falsenative-sso-supported默认trueCIBA 传输backchannel-token-delivery-modes-supported默认poll, ping, push算法清单dpop-signing-alg-values-supportedRS256/384/512, ES256/384/512、id-token-encryption-alg-values-supportedRSA1_5, RSA-OAEP, RSA-OAEP-256, A128KW … ECDH-ESA256KW等 13 种、对应的*_encryption_encoding_values_supportedA128CBC-HS256 … A256GCM6 种以及 userinfo / introspection / request-object 的同类字段——它们的默认值就是全量声明只有做算法白名单收敛时才需要逐一覆写acr-values-supported默认空列表但别急着填——见下一节 YAML 中所有键用 kebab-case 书写如claims-parameter-supported数组可用逗号分隔字符串或标准 YAML 列表。特殊行为acr_values_supported 会自动汇总已启用的 MFA这是整份配置里唯一一处不填比填更有用的逻辑实现在 OidcServerDiscoverySettingsFactory.java 的populateDiscovery中当acrValuesSupported为空时CAS 遍历应用上下文里全部MultifactorAuthenticationProvider把每个 Provider 的getId()收进acr_values_supported。为什么这么设计ACR认证上下文类是 MFA 能力在 OIDC 侧的映射手工维护容易与启用的 MFA 模块漂移——启用 Duo 忘了加 ACR 值客户端就不会用它发起 MFA。工厂自动推导后启用的 MFA 集合永远与元数据一致测试OidcServerDiscoverySettingsFactoryTests位于 support/cas-server-support-oidc/src/test/也断言了未显式配置时getAcrValuesSupported()非空。同一工厂还有几处配置没写、响应里却会出现的内容排查响应差异时别漏看scopes 是并集resolveScopesSupported会把cas.authn.oidc.vc.issuer.credential-configurations中每个可验证凭据配置的scope追加进scopes_supported去重后用于 OpenID4VCI 的凭据请求client attestation配置了 trust anchors 时自动追加attest_jwt_client_auth、attest_jwt_client_auth_dpop两种认证方法challenge 功能开启时再追加challenge_endpointVC 状态列表cas.authn.oidc.vc.issuer.status-list启用后追加status_list_aggregation_endpoint登出能力backchannel_logout_supported/frontchannel_logout_supported读取cas.authn.oidc.logout.backchannel-logout-supported/frontchannel-logout-supported均默认trueWebFinger用一个账号标识反查 issuer标准 Discovery 要求客户端先知道 issuerWebFinger 解决反向问题——只知道用户是谁如acct:casusersso.example.org问出他属于哪个 Provider。端点为/{context}/oidc/.well-known/webfinger响应类型application/jrdjson参数如下参数必填说明resource是资源标识典型值acct:userhost缺失时返回400 Bad Requestrel否关系类型标准值为http://openid.net/specs/connect/1.0/issuer常量WEBFINGER_REL命中时响应体形如{ subject: acct:casusersso.example.org, links: [ { rel: http://openid.net/specs/connect/1.0/issuer, href: https://sso.example.org/cas/oidc } ] }默认实现 OidcDefaultWebFingerDiscoveryService.java 的判定顺序值得知道它决定了什么请求会拿到 404resource与 issuer 完全一致忽略大小写→ 直接返回否则按resourcePattern正则cas.authn.oidc.webfinger.resource-pattern可覆盖归一化scheme 必须是acct用userinfo仓库先按邮箱findByEmailAddress、再按用户名findByUsername查找查无此人 → 404resource 的 host 与 issuer 的 host 不一致 → 404。userinfo仓库支持默认实现之外再接 Groovy 脚本或 REST 接口配置模型 OidcWebFingerProperties.javacas.authn.oidc.webfinger.enabled默认true。行为基准见 OidcWebFingerUserInfoRepositoryTests.java 与 OidcDefaultWebFingerDiscoveryServiceTests.java带rel与不带rel均返回 200缺resource返回 400。用 curl 验证三个端点并定制元数据部署完成后三条命令覆盖全部入口把域名换成你的部署# 标准 OIDC Discovery 文档 curl -s https://sso.example.org/cas/oidc/.well-known/openid-configuration # 裸 .well-known 端点输出应与上者一致 curl -s https://sso.example.org/cas/oidc/.well-known # WebFinger用账号反查 issuer curl -s https://sso.example.org/cas/oidc/.well-known/webfinger?resourceacct:casusersso.example.orgrelhttp://openid.net/specs/connect/1.0/issuer验收标准issuer、authorization_endpoint、token_endpoint、jwks_uri、scopes_supported、claims_supported均存在且端点前缀与 issuer 一致用未注册域名替换 Host 再请求应得到 404。一段可直接使用的定制示例收敛 scope/claim、收紧算法、开启 Identity Assurancecas: authn: oidc: issuer: https://sso.example.org/cas/oidc discovery: scopes: openid,profile,email,phone,offline_access claims: sub,name,email,email_verified,preferred_username response-types-supported: code response-modes-supported: query,fragment,form_post code-challenge-methods-supported: S256 id-token-signing-alg-values-supported: RS256,ES256 token-endpoint-auth-methods-supported: client_secret_basic,client_secret_post prompt-values-supported: none,login,consent verified-claims-supported: true trust-frameworks-supported: trust_framework_example改完任何cas.authn.oidc.discovery.*键后无需改代码重启或经配置刷新即在新响应中生效元数据由oidcServerDiscoverySettingsFactory以单例装配控制器直接返回该对象序列化结果。官方文档对应 OIDC-Authentication-Discovery.md其余 OIDC 能力配置参见 docs/cas-server-documentation/authentication/ 目录。常见误区与上线前检查清单误区一改了 issuerwell-known 打不开。多半不是端点坏了而是 issuer 校验按 Host 比对DNS/负载均衡上多挂的域名没有包含进 issuer 配置。先核对 issuer再看日志中 issuer for endpoint(s) ... is invalid 的告警。误区二手动往acr-values-supported里加 MFA 名称。留空即可工厂会自动汇总已注册的MultifactorAuthenticationProvider只有想手工收窄 ACR 集合时才显式赋值。误区三以为oauth-authorization-server是另一份元数据。它与openid-configuration同方法同响应只是给 RFC 8414 客户端的入口。误区四把token-endpoint-auth-methods里的none当成漏洞。它是无凭据客户端也可访问令牌端点的能力声明如钱包兑换 pre-authorized code是否保留取决于你的客户端形态。上线前清单三个端点各 curl 一次确认 200 关键字段或 WebFinger 的 400/404 负向路径也测过scopes_supported、claims_supported、签名算法清单与合规基线一致none类宽松项已按环境裁剪jwks_uri实际可达且公钥能解验 ID Token未注册域名访问 well-known 稳定返回 404无元数据泄漏启用的 MFA 模块与acr_values_supported输出一致自动推导场景下应自动吻合。【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址: https://gitcode.com/gh_mirrors/ca/cas创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考