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/authelia
Authelia 已于 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 Token |
| Hybrid 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 目前已支持并通过认证的元素包括:
- Core(OpenID Connect Core 1.0);
- Discovery(OpenID Connect Discovery 1.0);
- Form Post Response Mode(OAuth 2.0 Form Post Response Mode);
- 协议底层支撑(Protocol Underpinnings)中除WebFinger之外的全部元素,涉及 RFC 6749(OAuth 2.0)、RFC 6750(Bearer Token)、RFC 7515(JWS)、RFC 7516(JWE)、RFC 7517(JWK)、RFC 7518(JWA)、RFC 7519(JWT)、RFC 7521/7523(Assertion Framework / JWT Profile)、RFC 7033(WebFinger,未实现)等。
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_token; - Form 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、Implicit(id_token、token、id_token token)与 Hybrid(code token、code id_token、code id_token token)全部七种取值;grant_types_supported:authorization_code、implicit、client_credentials、refresh_token与 Device Code;response_modes_supported:form_post、query、fragment以及 JARM 的jwt、form_post.jwt、query.jwt、fragment.jwt;token_endpoint_auth_methods_supported:client_secret_basic、client_secret_post、client_secret_jwt、private_key_jwt与none;code_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 Flow | code | form_post、query |
| Implicit Flow | id_token token | form_post、fragment |
| Implicit Flow | id_token | form_post、fragment |
| Implicit Flow | token | form_post、fragment |
| Hybrid Flow | code token | form_post、fragment |
| Hybrid Flow | code id_token | form_post、fragment |
| Hybrid Flow | code id_token token | form_post、fragment |
3.2 支持的响应模式
| 名称 | 支持 | 值 |
|---|---|---|
| OAuth 2.0 Form Post | 是 | form_post |
| Query String | 是 | query |
| Fragment | 是 | fragment |
| JARM | 是 | jwt |
| Form Post (JARM) | 是 | form_post.jwt |
| Query String (JARM) | 是 | query.jwt |
| Fragment (JARM) | 是 | fragment.jwt |
3.3 端点实现一览
以下端点路径均以 Authelia 根 URL(即 OpenID Connect 1.0 Issuer)为前缀,客户端可通过 Discovery 端点自动发现:
| 端点 | 路径 |
|---|---|
| OpenID Connect Discovery 1.0 | /.well-known/openid-configuration |
| OAuth 2.0 Authorization Server Metadata | /.well-known/oauth-authorization-server |
| JSON Web Key Set | /jwks.json |
| Authorization | /api/oidc/authorization |
| Device Authorization | /api/oidc/device-authorization |
| Pushed Authorization Requests | /api/oidc/pushed-authorization-request |
| Token | /api/oidc/token |
| UserInfo | /api/oidc/userinfo |
| Introspection | /api/oidc/introspection |
| Revocation | /api/oidc/revocation |
四、认证之外的完整实现:安全强化特性
除了认证覆盖的五个配置文件,Authelia 还实现了一系列安全强化机制,集成文档对此有详细说明:
- Pushed Authorization Requests(PAR):客户端必须使用与 Token 端点相同的认证机制、通过 HTTP POST 在后通道提交授权请求,返回
request_uri与expires_in。可以全局或按客户端强制所有授权请求经由 PAR 发起,显著提升授权流程对钓鱼攻击的抵抗力; - OAuth 2.0 Authorization Server Issuer Identification:在授权响应中携带精确的 Issuer,供 Relying Party 在
state参数之外做额外校验; - JWT Secured Authorization Response Mode(JARM):对授权响应进行加密签名,确保响应未被篡改或伪造;
- Proof Key for Code Exchange(PKCE):使用 SHA-256 对
code_verifier做摘要并 Base64URL 编码生成code_challenge,S256 方式可缓解授权码拦截攻击,且对无法在 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 服务的域名都必须显式配置对应的 Issuer;
- Issuer 与 Client 的数据库存储:这已成为明显需求。不会移除通过配置文件配置的选项,但多项新功能将依赖数据库存储这一选项。
5.2 高影响力规范扩展(对应多个 OP Profile)
- Dynamic Client Registration(Dynamic OP Profile);
- Session Management(Session OP Profile);
- Front-Channel Logout(Front-Channel OP Profile);
- Back-Channel Logout(Back-Channel OP Profile);
- RP-Initiated Logout(RP-Initiated OP Profile);
- Client Initiated Backchannel Authentication Flow(CIBA)(3rd Party-Init OP Profile);
- OAuth 2.0 Token Exchange。
5.3 其他规划方向
- 完整实现 Authentication Method References(
amr):通过允许基于认证方法引用的自定义授权策略,为管理员提供细粒度的授权控制; - WebFinger;
- Federated Credential Management(FedCM);
- 实现 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 1~Beta 7(已完成,对应 v4.29.0~v4.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 JWK(RS/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 Identifier(PPID)与 Sector Identifier 校验等; - Beta 9:Session Management、Back-Channel/Front-Channel Logout、RP-Initiated Logout、CIBA;
- General Availability:提供官方稳定性保证。
六、规格支持透明度:Support Chart 与文档指引
公告还更新了 OpenID Connect 1.0 集成文档 中的 支持图表,该图表列出了绝大多数与 Authelia 相关、且更有可能在未来被实现的 OpenID Connect 1.0 与 OAuth 2.0 规范,每项标注Certified / Complete / Partial / None四种状态。例如:
- Certified:OpenID Connect Core 1.0、Discovery 1.0、OAuth 2.0 Multiple Response Types、OAuth 2.0 Form Post Response Mode、PKCE、OAuth 2.0 Core;
- Complete:Token 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 等;
- Partial:RFC 7523 客户端认证、FAPI 2.0 Security Profile / Message Signing / Attacker Model;
- None:Dynamic 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),仅供参考