Authelia 通过 OpenID Certified™ 认证OpenID Connect 1.0 提供方实现与路线图深度解析【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/autheliaAuthelia 已于 2025 年 5 月正式通过 OpenID 基金会的OpenID Certified™认证其 OpenID Connect 1.0 Provider 实现获得了 Basic OP、Implicit OP、Hybrid OP、Form Post OP 与 Config OP 五个配置文件的官方一致性认证。本文以该项目官方公告为基础结合仓库中的集成文档、路线图与源码系统讲解认证覆盖范围、已实现的协议能力、支撑认证的工程化手段以及项目在 SSO 领域接下来的演进路线。一、认证公告Authelia 成为 OpenID Certified™ 官方认证的 OP 实现官方公告见 docs/content/blog/we-are-now-openid-certified/index.md确认Authelia 的 OpenID Connect 1.0 Provider 已正式通过 OpenID 基金会的一致性测试套件Conformance Suite获准使用OpenID Certified™认证标志。这是 Authelia 项目发展历程中的一个重要里程碑。1.1 认证覆盖的五个 OP 配置文件Profiles配置文件说明Basic OP基于 Authorization Code Flow 的基础提供方配置对应 OpenID Connect Core 1.0 的强制实现要求Implicit OP基于 Implicit Flow 的提供方配置直接在授权端点返回 ID Token / Access TokenHybrid OP混合流提供方配置同时使用授权码与隐式返回的令牌Form Post OP使用 Form Post 响应模式OAuth 2.0 Form Post Response Mode的提供方配置Config OP基于 OpenID Connect Discovery 1.0 的配置发现提供方配置认证的意义在于通过一致性测试意味着实现在所有已实现且具备一致性测试的领域均符合规范。很多提供方无法达到这一验证水平。认证从两个方面为用户带来价值互操作性保障认证证明实现与其他遵循 OpenID Connect 1.0 协议的系统之间具备良好的互操作能力安全与隐私实践佐证虽然认证本身不能绝对证明实现是安全的但它显著提升了可信度——尤其考虑到业界其他 OpenID Connect 1.0 Provider 曾出现过本应被一致性测试拦截的 CVE 漏洞。Authelia OpenID Certified 认证徽标公告还提到认证过程中 OpenID 基金会响应迅速——从问题上报、PR 起草、修复发布到新版本发布整个过程不超过 24 小时。1.2 已通过认证的协议元素在 OpenID Connect 1.0 协议套件中Authelia 目前已支持并通过认证的元素包括CoreOpenID Connect Core 1.0DiscoveryOpenID Connect Discovery 1.0Form Post Response ModeOAuth 2.0 Form Post Response Mode协议底层支撑Protocol Underpinnings中除WebFinger之外的全部元素涉及 RFC 6749OAuth 2.0、RFC 6750Bearer Token、RFC 7515JWS、RFC 7516JWE、RFC 7517JWK、RFC 7518JWA、RFC 7519JWT、RFC 7521/7523Assertion Framework / JWT Profile、RFC 7033WebFinger未实现等。OpenID Connect 1.0 协议套件全景图剩余两个明显目标——Dynamic Client Registration动态客户端注册与Session Management会话管理——虽然不是强制要求但非常实用官方表示正在推进。二、认证背后的工程化支撑源码级证据认证并非一次性行为而是由持续性的工程实践支撑的。仓库中有两处可以直接印证这一点。2.1 一致性测试套件的自动化生成在 cmd/authelia-gen/openid_conformance.go 中Authelia 通过OpenIDConnectConformanceSuiteBuilder为每个认证测试计划生成对应的配置针对oidcc-basic-certification-test-plan、oidcc-formpost-basic-certification-test-plan、oidcc-hybrid-certification-test-plan、oidcc-formpost-hybrid-certification-test-plan、oidcc-implicit-certification-test-plan、oidcc-formpost-implicit-certification-test-plan以及oidcc-config-certification-test-plan等测试计划生成一致性套件生成的客户端配置会按测试计划切换grant_types、response_types与response_modes。例如 Implicit/Hybrid 测试计划使用authorization_code、implicit、refresh_token等授权类型组合而 Basic 计划仅使用authorization_code与refresh_tokenForm Post 变体配置form_post与form_post.jwt响应模式非 Form Post 变体配置query与query.jwt客户端密钥通过 PBKDF2 摘要MustHash存储AuthorizationPolicy与ConsentMode按需注入。这表明认证过程中的每个测试计划都有对应的可重复生成的客户端配置支持对每个 Authelia 版本持续执行一致性测试以维持最新的认证标准。2.2 Discovery 元数据认证能力的对外声明在 internal/oidc/discovery.go 中NewOpenIDConnectWellKnownConfiguration生成了.well-known/openid-configuration返回的完整元数据与认证范围一一对应response_types_supported涵盖 Authorization Code、Implicitid_token、token、id_token token与 Hybridcode token、code id_token、code id_token token全部七种取值grant_types_supportedauthorization_code、implicit、client_credentials、refresh_token与 Device Coderesponse_modes_supportedform_post、query、fragment以及 JARM 的jwt、form_post.jwt、query.jwt、fragment.jwttoken_endpoint_auth_methods_supportedclient_secret_basic、client_secret_post、client_secret_jwt、private_key_jwt与nonecode_challenge_methods_supported默认仅S256可通过配置启用plain签名算法列表由SigningAlgValuesSupported统一生成包含 HS256/384/512、RS256/384/512、PS256/384/512、ES256/384/512、Ed25519、EdDSA并根据构建工具链是否支持crypto/mldsa决定是否追加 ML-DSA-44/65/87。三、认证能力清单响应类型、响应模式与端点实现根据集成文档 docs/content/integration/openid-connect/introduction.md以下是认证所覆盖能力的完整清单。3.1 支持的响应类型与默认响应模式流程类型值response_type默认响应模式Authorization Code Flowcodeform_post、queryImplicit Flowid_token tokenform_post、fragmentImplicit Flowid_tokenform_post、fragmentImplicit Flowtokenform_post、fragmentHybrid Flowcode tokenform_post、fragmentHybrid Flowcode id_tokenform_post、fragmentHybrid Flowcode id_token tokenform_post、fragment3.2 支持的响应模式名称支持值OAuth 2.0 Form Post是form_postQuery String是queryFragment是fragmentJARM是jwtForm Post (JARM)是form_post.jwtQuery String (JARM)是query.jwtFragment (JARM)是fragment.jwt3.3 端点实现一览以下端点路径均以 Authelia 根 URL即 OpenID Connect 1.0 Issuer为前缀客户端可通过 Discovery 端点自动发现端点路径OpenID Connect Discovery 1.0/.well-known/openid-configurationOAuth 2.0 Authorization Server Metadata/.well-known/oauth-authorization-serverJSON Web Key Set/jwks.jsonAuthorization/api/oidc/authorizationDevice Authorization/api/oidc/device-authorizationPushed Authorization Requests/api/oidc/pushed-authorization-requestToken/api/oidc/tokenUserInfo/api/oidc/userinfoIntrospection/api/oidc/introspectionRevocation/api/oidc/revocation四、认证之外的完整实现安全强化特性除了认证覆盖的五个配置文件Authelia 还实现了一系列安全强化机制集成文档对此有详细说明Pushed Authorization RequestsPAR客户端必须使用与 Token 端点相同的认证机制、通过 HTTP POST 在后通道提交授权请求返回request_uri与expires_in。可以全局或按客户端强制所有授权请求经由 PAR 发起显著提升授权流程对钓鱼攻击的抵抗力OAuth 2.0 Authorization Server Issuer Identification在授权响应中携带精确的 Issuer供 Relying Party 在state参数之外做额外校验JWT Secured Authorization Response ModeJARM对授权响应进行加密签名确保响应未被篡改或伪造Proof Key for Code ExchangePKCE使用 SHA-256 对code_verifier做摘要并 Base64URL 编码生成code_challengeS256 方式可缓解授权码拦截攻击且对无法在 Token 端点认证的 public 客户端同样生效。五、未来路线认证之后Authelia 的 OpenID Connect 1.0 演进计划公告明确指出认证只是阶段性成果OpenID Connect 1.0 功能目前仍处于实验/测试beta阶段在移除该状态之前还有若干工作多为传统意义上的破坏性变更需要完成。5.1 完成 OpenID Connect 1.0 实现本身重构 Consent Policies同意策略使其像其他策略一样可复用并确保它只表达“客户端未显式要求特定行为时的默认行为”。例如prompt参数可以要求显示登录、账号选择、同意界面或要求不向用户展示任何内容实现 Multi-Issuer 配置与多域名配置配套每个需要提供 OpenID Connect 1.0 服务的域名都必须显式配置对应的 IssuerIssuer 与 Client 的数据库存储这已成为明显需求。不会移除通过配置文件配置的选项但多项新功能将依赖数据库存储这一选项。5.2 高影响力规范扩展对应多个 OP ProfileDynamic Client RegistrationDynamic OP ProfileSession ManagementSession OP ProfileFront-Channel LogoutFront-Channel OP ProfileBack-Channel LogoutBack-Channel OP ProfileRP-Initiated LogoutRP-Initiated OP ProfileClient Initiated Backchannel Authentication FlowCIBA3rd Party-Init OP ProfileOAuth 2.0 Token Exchange。5.3 其他规划方向完整实现 Authentication Method Referencesamr通过允许基于认证方法引用的自定义授权策略为管理员提供细粒度的授权控制WebFingerFederated Credential ManagementFedCM实现 OpenID Connect 1.0 Relying Party 角色允许用户将社交账号关联到其他 OpenID Connect 1.0 Provider 并以其登录管理员可配置信任来自这些 Provider 的认证方法引用以实现无缝 SSO对不信任的 Provider 仅假定提供了密码SAML 2.0这是一个被广泛请求的功能官方明确表示将实现但希望先打好坚实基础。这些内容在 docs/content/roadmap/active/openid-connect-1.0-provider.md 中有更细粒度的阶段划分Beta 1Beta 7已完成对应 v4.29.0v4.39.0从 Authorization Code Flow、Discovery、RS256 起步逐步加入 Userinfo、PKCE、持久化存储与 opaque UUID v4 subject、X.509 证书链 JWK、三种 Consent Mode、RFC 9068 JWT Access Token、PAR、JARM、client_secret_jwt/private_key_jwt客户端认证、Client Credentials Grant、多 Issuer JWKRS/PS/ES 系列、Client RBAC用户/组/网络、自定义 Claims 与 Scopes、Device Authorization Grant 等Beta 8进行中对应 v4.40.0涉及若干破坏性变更移除明文密码存储、Consent Policy 重构重点实现存储内配置JWK 轮换、Multi-Issuer 配置、Dynamic Client Registration规范 特殊不透明令牌authelia_dcrt_*、CLI、YAML 导入/引导、Pairwise Pseudonymous IdentifierPPID与 Sector Identifier 校验等Beta 9Session Management、Back-Channel/Front-Channel Logout、RP-Initiated Logout、CIBAGeneral Availability提供官方稳定性保证。六、规格支持透明度Support Chart 与文档指引公告还更新了 OpenID Connect 1.0 集成文档 中的 支持图表该图表列出了绝大多数与 Authelia 相关、且更有可能在未来被实现的 OpenID Connect 1.0 与 OAuth 2.0 规范每项标注Certified / Complete / Partial / None四种状态。例如CertifiedOpenID Connect Core 1.0、Discovery 1.0、OAuth 2.0 Multiple Response Types、OAuth 2.0 Form Post Response Mode、PKCE、OAuth 2.0 CoreCompleteToken Revocation、Token Introspection、JWT Introspection Response、Authorization Server Metadata、PAR、Device Flow、RFC 9068 JWT Access Token、Resource Indicators、Bearer Tokens、Private Key JWT、JWT-Secured Authorization Request、Issuer Identification、JARM、RFC 8176 AMR 等PartialRFC 7523 客户端认证、FAPI 2.0 Security Profile / Message Signing / Attacker ModelNoneDynamic Client Registration、RP-Initiated Logout、Session Management、前后通道注销、CIBA、Token Exchange、DPoP、mTLS、Rich Authorization Requests、SAML 2.0 Profile 等多数与上述路线图一一对应。该图表与 OpenID Connect 1.0 Provider 路线图 共同构成 Authelia 在 OpenID Connect 1.0 领域未来发展的文档化依据也为其他希望透明公开其支持水平的项目提供了可参照的模板。七、如何在你的部署中体验认证范围内的能力OpenID Connect 1.0 功能默认不启用需要显式配置以下两部分OpenID Connect 1.0 Provider 配置定义 Issuer、JWK、授权策略、Claims 策略等OpenID Connect 1.0 Clients 配置注册 Relying Party 客户端按客户端配置response_types、grant_types、response_modes、token_endpoint_auth_method、userinfo_signed_response_alg、introspection_signed_response_alg等参数。配置完成后Relying Party 可通过/.well-known/openid-configuration发现全部端点与元数据能力声明见 internal/oidc/discovery.go即可接入经过 OpenID Certified™ 认证的 Authelia OP。有关社区讨论与支持渠道可参阅联系方式页面。总结OpenID Certified™ 认证是对 Authelia OpenID Connect 1.0 Provider 实现规范符合度的权威背书覆盖 Basic、Implicit、Hybrid、Form Post 与 Config 五个 OP 配置文件。认证背后是自动化的一致性测试套件生成、完整的 Discovery 元数据声明以及覆盖 PAR、JARM、PKCE、Issuer Identification 等安全强化特性。与此同时官方路线图清晰呈现了从“认证通过”走向“General Availability”的路径——动态客户端注册、多 Issuer、会话管理与各类注销规范、CIBA、Relying Party 角色乃至 SAML 2.0 都在规划之中值得持续关注。【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/authelia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Authelia 通过 OpenID Certified™ 认证：OpenID Connect 1.0 提供方实现与路线图深度解析
Authelia 通过 OpenID Certified™ 认证OpenID Connect 1.0 提供方实现与路线图深度解析【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/autheliaAuthelia 已于 2025 年 5 月正式通过 OpenID 基金会的OpenID Certified™认证其 OpenID Connect 1.0 Provider 实现获得了 Basic OP、Implicit OP、Hybrid OP、Form Post OP 与 Config OP 五个配置文件的官方一致性认证。本文以该项目官方公告为基础结合仓库中的集成文档、路线图与源码系统讲解认证覆盖范围、已实现的协议能力、支撑认证的工程化手段以及项目在 SSO 领域接下来的演进路线。一、认证公告Authelia 成为 OpenID Certified™ 官方认证的 OP 实现官方公告见 docs/content/blog/we-are-now-openid-certified/index.md确认Authelia 的 OpenID Connect 1.0 Provider 已正式通过 OpenID 基金会的一致性测试套件Conformance Suite获准使用OpenID Certified™认证标志。这是 Authelia 项目发展历程中的一个重要里程碑。1.1 认证覆盖的五个 OP 配置文件Profiles配置文件说明Basic OP基于 Authorization Code Flow 的基础提供方配置对应 OpenID Connect Core 1.0 的强制实现要求Implicit OP基于 Implicit Flow 的提供方配置直接在授权端点返回 ID Token / Access TokenHybrid OP混合流提供方配置同时使用授权码与隐式返回的令牌Form Post OP使用 Form Post 响应模式OAuth 2.0 Form Post Response Mode的提供方配置Config OP基于 OpenID Connect Discovery 1.0 的配置发现提供方配置认证的意义在于通过一致性测试意味着实现在所有已实现且具备一致性测试的领域均符合规范。很多提供方无法达到这一验证水平。认证从两个方面为用户带来价值互操作性保障认证证明实现与其他遵循 OpenID Connect 1.0 协议的系统之间具备良好的互操作能力安全与隐私实践佐证虽然认证本身不能绝对证明实现是安全的但它显著提升了可信度——尤其考虑到业界其他 OpenID Connect 1.0 Provider 曾出现过本应被一致性测试拦截的 CVE 漏洞。Authelia OpenID Certified 认证徽标公告还提到认证过程中 OpenID 基金会响应迅速——从问题上报、PR 起草、修复发布到新版本发布整个过程不超过 24 小时。1.2 已通过认证的协议元素在 OpenID Connect 1.0 协议套件中Authelia 目前已支持并通过认证的元素包括CoreOpenID Connect Core 1.0DiscoveryOpenID Connect Discovery 1.0Form Post Response ModeOAuth 2.0 Form Post Response Mode协议底层支撑Protocol Underpinnings中除WebFinger之外的全部元素涉及 RFC 6749OAuth 2.0、RFC 6750Bearer Token、RFC 7515JWS、RFC 7516JWE、RFC 7517JWK、RFC 7518JWA、RFC 7519JWT、RFC 7521/7523Assertion Framework / JWT Profile、RFC 7033WebFinger未实现等。OpenID Connect 1.0 协议套件全景图剩余两个明显目标——Dynamic Client Registration动态客户端注册与Session Management会话管理——虽然不是强制要求但非常实用官方表示正在推进。二、认证背后的工程化支撑源码级证据认证并非一次性行为而是由持续性的工程实践支撑的。仓库中有两处可以直接印证这一点。2.1 一致性测试套件的自动化生成在 cmd/authelia-gen/openid_conformance.go 中Authelia 通过OpenIDConnectConformanceSuiteBuilder为每个认证测试计划生成对应的配置针对oidcc-basic-certification-test-plan、oidcc-formpost-basic-certification-test-plan、oidcc-hybrid-certification-test-plan、oidcc-formpost-hybrid-certification-test-plan、oidcc-implicit-certification-test-plan、oidcc-formpost-implicit-certification-test-plan以及oidcc-config-certification-test-plan等测试计划生成一致性套件生成的客户端配置会按测试计划切换grant_types、response_types与response_modes。例如 Implicit/Hybrid 测试计划使用authorization_code、implicit、refresh_token等授权类型组合而 Basic 计划仅使用authorization_code与refresh_tokenForm Post 变体配置form_post与form_post.jwt响应模式非 Form Post 变体配置query与query.jwt客户端密钥通过 PBKDF2 摘要MustHash存储AuthorizationPolicy与ConsentMode按需注入。这表明认证过程中的每个测试计划都有对应的可重复生成的客户端配置支持对每个 Authelia 版本持续执行一致性测试以维持最新的认证标准。2.2 Discovery 元数据认证能力的对外声明在 internal/oidc/discovery.go 中NewOpenIDConnectWellKnownConfiguration生成了.well-known/openid-configuration返回的完整元数据与认证范围一一对应response_types_supported涵盖 Authorization Code、Implicitid_token、token、id_token token与 Hybridcode token、code id_token、code id_token token全部七种取值grant_types_supportedauthorization_code、implicit、client_credentials、refresh_token与 Device Coderesponse_modes_supportedform_post、query、fragment以及 JARM 的jwt、form_post.jwt、query.jwt、fragment.jwttoken_endpoint_auth_methods_supportedclient_secret_basic、client_secret_post、client_secret_jwt、private_key_jwt与nonecode_challenge_methods_supported默认仅S256可通过配置启用plain签名算法列表由SigningAlgValuesSupported统一生成包含 HS256/384/512、RS256/384/512、PS256/384/512、ES256/384/512、Ed25519、EdDSA并根据构建工具链是否支持crypto/mldsa决定是否追加 ML-DSA-44/65/87。三、认证能力清单响应类型、响应模式与端点实现根据集成文档 docs/content/integration/openid-connect/introduction.md以下是认证所覆盖能力的完整清单。3.1 支持的响应类型与默认响应模式流程类型值response_type默认响应模式Authorization Code Flowcodeform_post、queryImplicit Flowid_token tokenform_post、fragmentImplicit Flowid_tokenform_post、fragmentImplicit Flowtokenform_post、fragmentHybrid Flowcode tokenform_post、fragmentHybrid Flowcode id_tokenform_post、fragmentHybrid Flowcode id_token tokenform_post、fragment3.2 支持的响应模式名称支持值OAuth 2.0 Form Post是form_postQuery String是queryFragment是fragmentJARM是jwtForm Post (JARM)是form_post.jwtQuery String (JARM)是query.jwtFragment (JARM)是fragment.jwt3.3 端点实现一览以下端点路径均以 Authelia 根 URL即 OpenID Connect 1.0 Issuer为前缀客户端可通过 Discovery 端点自动发现端点路径OpenID Connect Discovery 1.0/.well-known/openid-configurationOAuth 2.0 Authorization Server Metadata/.well-known/oauth-authorization-serverJSON Web Key Set/jwks.jsonAuthorization/api/oidc/authorizationDevice Authorization/api/oidc/device-authorizationPushed Authorization Requests/api/oidc/pushed-authorization-requestToken/api/oidc/tokenUserInfo/api/oidc/userinfoIntrospection/api/oidc/introspectionRevocation/api/oidc/revocation四、认证之外的完整实现安全强化特性除了认证覆盖的五个配置文件Authelia 还实现了一系列安全强化机制集成文档对此有详细说明Pushed Authorization RequestsPAR客户端必须使用与 Token 端点相同的认证机制、通过 HTTP POST 在后通道提交授权请求返回request_uri与expires_in。可以全局或按客户端强制所有授权请求经由 PAR 发起显著提升授权流程对钓鱼攻击的抵抗力OAuth 2.0 Authorization Server Issuer Identification在授权响应中携带精确的 Issuer供 Relying Party 在state参数之外做额外校验JWT Secured Authorization Response ModeJARM对授权响应进行加密签名确保响应未被篡改或伪造Proof Key for Code ExchangePKCE使用 SHA-256 对code_verifier做摘要并 Base64URL 编码生成code_challengeS256 方式可缓解授权码拦截攻击且对无法在 Token 端点认证的 public 客户端同样生效。五、未来路线认证之后Authelia 的 OpenID Connect 1.0 演进计划公告明确指出认证只是阶段性成果OpenID Connect 1.0 功能目前仍处于实验/测试beta阶段在移除该状态之前还有若干工作多为传统意义上的破坏性变更需要完成。5.1 完成 OpenID Connect 1.0 实现本身重构 Consent Policies同意策略使其像其他策略一样可复用并确保它只表达“客户端未显式要求特定行为时的默认行为”。例如prompt参数可以要求显示登录、账号选择、同意界面或要求不向用户展示任何内容实现 Multi-Issuer 配置与多域名配置配套每个需要提供 OpenID Connect 1.0 服务的域名都必须显式配置对应的 IssuerIssuer 与 Client 的数据库存储这已成为明显需求。不会移除通过配置文件配置的选项但多项新功能将依赖数据库存储这一选项。5.2 高影响力规范扩展对应多个 OP ProfileDynamic Client RegistrationDynamic OP ProfileSession ManagementSession OP ProfileFront-Channel LogoutFront-Channel OP ProfileBack-Channel LogoutBack-Channel OP ProfileRP-Initiated LogoutRP-Initiated OP ProfileClient Initiated Backchannel Authentication FlowCIBA3rd Party-Init OP ProfileOAuth 2.0 Token Exchange。5.3 其他规划方向完整实现 Authentication Method Referencesamr通过允许基于认证方法引用的自定义授权策略为管理员提供细粒度的授权控制WebFingerFederated Credential ManagementFedCM实现 OpenID Connect 1.0 Relying Party 角色允许用户将社交账号关联到其他 OpenID Connect 1.0 Provider 并以其登录管理员可配置信任来自这些 Provider 的认证方法引用以实现无缝 SSO对不信任的 Provider 仅假定提供了密码SAML 2.0这是一个被广泛请求的功能官方明确表示将实现但希望先打好坚实基础。这些内容在 docs/content/roadmap/active/openid-connect-1.0-provider.md 中有更细粒度的阶段划分Beta 1Beta 7已完成对应 v4.29.0v4.39.0从 Authorization Code Flow、Discovery、RS256 起步逐步加入 Userinfo、PKCE、持久化存储与 opaque UUID v4 subject、X.509 证书链 JWK、三种 Consent Mode、RFC 9068 JWT Access Token、PAR、JARM、client_secret_jwt/private_key_jwt客户端认证、Client Credentials Grant、多 Issuer JWKRS/PS/ES 系列、Client RBAC用户/组/网络、自定义 Claims 与 Scopes、Device Authorization Grant 等Beta 8进行中对应 v4.40.0涉及若干破坏性变更移除明文密码存储、Consent Policy 重构重点实现存储内配置JWK 轮换、Multi-Issuer 配置、Dynamic Client Registration规范 特殊不透明令牌authelia_dcrt_*、CLI、YAML 导入/引导、Pairwise Pseudonymous IdentifierPPID与 Sector Identifier 校验等Beta 9Session Management、Back-Channel/Front-Channel Logout、RP-Initiated Logout、CIBAGeneral Availability提供官方稳定性保证。六、规格支持透明度Support Chart 与文档指引公告还更新了 OpenID Connect 1.0 集成文档 中的 支持图表该图表列出了绝大多数与 Authelia 相关、且更有可能在未来被实现的 OpenID Connect 1.0 与 OAuth 2.0 规范每项标注Certified / Complete / Partial / None四种状态。例如CertifiedOpenID Connect Core 1.0、Discovery 1.0、OAuth 2.0 Multiple Response Types、OAuth 2.0 Form Post Response Mode、PKCE、OAuth 2.0 CoreCompleteToken Revocation、Token Introspection、JWT Introspection Response、Authorization Server Metadata、PAR、Device Flow、RFC 9068 JWT Access Token、Resource Indicators、Bearer Tokens、Private Key JWT、JWT-Secured Authorization Request、Issuer Identification、JARM、RFC 8176 AMR 等PartialRFC 7523 客户端认证、FAPI 2.0 Security Profile / Message Signing / Attacker ModelNoneDynamic Client Registration、RP-Initiated Logout、Session Management、前后通道注销、CIBA、Token Exchange、DPoP、mTLS、Rich Authorization Requests、SAML 2.0 Profile 等多数与上述路线图一一对应。该图表与 OpenID Connect 1.0 Provider 路线图 共同构成 Authelia 在 OpenID Connect 1.0 领域未来发展的文档化依据也为其他希望透明公开其支持水平的项目提供了可参照的模板。七、如何在你的部署中体验认证范围内的能力OpenID Connect 1.0 功能默认不启用需要显式配置以下两部分OpenID Connect 1.0 Provider 配置定义 Issuer、JWK、授权策略、Claims 策略等OpenID Connect 1.0 Clients 配置注册 Relying Party 客户端按客户端配置response_types、grant_types、response_modes、token_endpoint_auth_method、userinfo_signed_response_alg、introspection_signed_response_alg等参数。配置完成后Relying Party 可通过/.well-known/openid-configuration发现全部端点与元数据能力声明见 internal/oidc/discovery.go即可接入经过 OpenID Certified™ 认证的 Authelia OP。有关社区讨论与支持渠道可参阅联系方式页面。总结OpenID Certified™ 认证是对 Authelia OpenID Connect 1.0 Provider 实现规范符合度的权威背书覆盖 Basic、Implicit、Hybrid、Form Post 与 Config 五个 OP 配置文件。认证背后是自动化的一致性测试套件生成、完整的 Discovery 元数据声明以及覆盖 PAR、JARM、PKCE、Issuer Identification 等安全强化特性。与此同时官方路线图清晰呈现了从“认证通过”走向“General Availability”的路径——动态客户端注册、多 Issuer、会话管理与各类注销规范、CIBA、Relying Party 角色乃至 SAML 2.0 都在规划之中值得持续关注。【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/authelia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考