Authelia 路线图全解读从 OpenID Connect 到多域保护的产品规划与实现进展【免费下载链接】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 官方文档中的路线图引言Prologue展开系统梳理了 Authelia 团队对产品未来的公开规划包括处于 Planning规划、Active进行中与 Complete已完成三个阶段的全部功能条目以及每个条目背后的设计思路、阶段划分与版本落地情况。读完本文你将完整掌握 Authelia 各核心功能OpenID Connect 1.0 Provider、粒度化授权、多域保护、用户/管理员控制面板、WebAuthn 等的演进脉络并能借助仓库中的源码、配置样例与参考指南深入验证每一项规划的实际实现状态。路线图的定位与阅读原则路线图引言docs/content/roadmap/prologue/introduction.md首先交代了 Authelia 团队的背景Authelia 团队由 3 名分布在全球的开发者组成利用业余时间持续改进 Authelia并基于一份对外公开的路线图来确定优先级以此保持透明度。团队一方面尽可能平衡新功能与改进另一方面必须投入精力完成维护任务将未解决问题open issues积压控制在一个合理水平。文档同时鼓励社区贡献者通过 Matrix 联系团队共同分享想法与计划。在阅读路线图时有一条重要提醒必须留意路线图条目中列出的版本号除非被标注为已完成completed否则都是预估版本intended estimation。计划可能发生变化团队也可能忘记更新版本号如果读者发现版本号有误可以通过 GitHub Discussion 或聊天渠道反馈。从源码结构看路线图文档体系位于 docs/content/roadmap/ 目录按planning/规划、active/进行中、complete/已完成、prologue/引言四个子目录组织每个条目对应一篇独立的 Markdown 文档使用{{ roadmap-status stage... version... }}短代码标注阶段与目标版本。这种状态徽章式的组织方式让社区可以直观地追踪每个功能的推进情况。Planning 阶段处于早期规划的功能处于 Planning 阶段的功能计划实施但仍处于非常早期的规划阶段目前包含两项都与让 Authelia 作为身份提供者IdP之外的角色参与更多生态相关。OpenID Connect 1.0 Relying Party依赖方OpenID Connect 1.0 Relying Party 条目指出Relying PartyRP角色通常被描述为客户端RP 依赖某个 OpenID Connect 1.0 Provider 来获取认证与授权信息把校验工作委托给 Provider。该条目按三个子主题拆分了设计思路Anchoring Implementation账户锚定为了让 RP 模式可用用户必须能把其 Provider 账号锚定到 Authelia 账号上。从文档描述推断较可能的实现是用户需先以满足two_factor策略的认证级别登录然后点击一个引导链接完成 onboard。账户之间将很可能通过成对pairwise的iss与sub声明即 issuer 与 subject identifier建立关联。文档还链接了 integration/openid-connect/frequently-asked-questions.md 中关于如何在应用中把用户账号与 Authelia 的 OpenID Connect 1.0 响应关联起来的 FAQ用以解释选择这两个声明的理由。Authorization Implementation授权实现授权时对用户的识别同样会使用此前锚定的成对iss与sub声明。从交互形态看这一功能很可能看起来与 Login with Passkey 按钮类似并提供一定的布局定制能力单独展示、放入菜单、或两者组合。Authentication Methods Reference Values认证方法引用值文档设想理论上可以结合 Granular Authorization粒度化授权用 AMR 值推导用户的有效认证级别并且很可能会以可选开启信任 Provideropt-in的设定来实现。关于 AMR 的具体含义可参考 reference/guides/authentication-method-references.md。Security Assertion Markup Language (SAML) 2.0 ProviderSAML 2.0 Provider 条目指出SAML 2.0 Provider 实现与 OpenID Connect 1.0 Provider 有诸多相同收益但面向的是支持 SAML 而非 OIDC 的客户端。目前该条目只有一个进行中的阶段Decide On a Library选定依赖库。文档强调市面上可用的成熟库不多且 SAML 2.0 基于 XML 的协议设计存在许多陷阱团队需要非常谨慎地评估所有选项。Active 阶段正在优先推进的功能Active 条目是正在积极开发、属于发展方向优先级的项目目前包含 6 项。以下逐项展开。OpenID Connect 1.0 ProviderOpenID Connect 1.0 Provider 是路线图中体量最大、粒度最细的条目。团队决定将 OAuth 2.0 与 OpenID Connect 1.0 以beta 特性形式实现虽然相对稳定但随着规范各环节的逐步落实可能不可避免地出现偶发破坏性变更因此建议使用该特性时比多数特性更谨慎。OIDC 及其相关端点默认不启用必须显式配置 OpenID Connect 1.0 Provider Configuration 与 OpenID Connect 1.0 Registered Clients 两个配置节才会生效。由于 OIDC尤其 Provider 角色相当复杂团队刻意以 beta 形式、并借助深思熟虑的路线图推进避免安全问题。OpenID Certified™Authelia 已通过 OpenID 认证符合 OpenID Connect 协议规范。认证详情见 integration/openid-connect/introduction.md 中的 OpenID Certified 章节该条目按 Beta 1 至 Beta 9 及 General Availability正式可用划分实施阶段每个阶段标注了落地版本阶段状态版本核心内容Beta 1已完成v4.29.0用户同意User Consent、授权码流程Authorization Code Flow、OIDC Discovery、RS256 签名策略、按客户端限制 scope/grant type/response type、按客户端授权策略1FA/2FA、合法重定向 URI 白名单、机密客户端Confidential ClientBeta 2已完成v4.30.0Userinfo 端点、参数熵、Token/Code 有效期、客户端调试消息、客户端 Audience、公共客户端Public ClientBeta 3已完成v4.34.0RFC 7636 PKCE授权码流程、preferred_username声明替代sub发送用户名Beta 4已完成v4.35.0持久化存储Token、可审计信息、subject 到用户映射、不透明 UUID v4 subject 标识符、pairwise/plain subject 类型采用 pairwise 示例方法 3、sub/amr/azp/client_id声明、CORS 支持Beta 5已完成v4.37.0X509 证书链支持的 JWK、客户端密钥哈希、按客户端的 Consent 模式Explicit/Implicit/Pre-ConfiguredBeta 6已完成v4.38.0RFC 9068 JWT Profile、RFC 9126 PAR、RFC 9207 Issuer Identification、RFC 6750 Bearer Token、JARM、JWT Token Inspection、RFC 7523client_secret_jwt/private_key_jwt、按客户端 PKCE 策略与 Token 有效期、Client Credentials Grant、多 Issuer JWKRS/PS/ES 系列、Client RBAC: Users and GroupsBeta 7已完成v4.39.0Prompt/Display/Claims 处理、自定义 Claims 策略、属性映射、自定义 Scopes、RFC 8628 设备授权流、JWE、Client RBAC: Networks同时包含破坏性变更默认 ID Token 声明调整、移除遗留端点Beta 8进行中v4.40.0存储内配置JWK 轮换、Multi-Issuer Configuration、基于规范的动态客户端注册authelia_dcrt_*、CLI 注册、YAML 导入、随机盐/加密胡椒化客户端凭证、Subject SectoringPPID、Sector Identifier 校验破坏性变更包括移除明文密码HMAC 类客户端认证方法除外与 Consent 策略重构Beta 9规划中—OpenID Connect Session Management、Back-Channel Logout、Front-Channel Logout、RP-Initiated Logout、CIBAGA规划中—对已实现特性提供官方稳定性保证此外条目还列出了一些**杂项Miscellaneous**规划Multi-Issuer Configuration计划中的破坏性变更要求每个需要提供 OIDC 服务的域名配置一个 Issuer彼此是完全独立的逻辑单元、OAuth 2.0 Authorization Server MetadataRFC 8414已完成于 v4.34.0、OAuth 2.0 Token ExchangeRFC 8693、动态客户端注册与注册管理协议、OIDC FAPI 2.0 安全配置文件进行中等。需要特别说明的是Beta 7 与 Beta 8 均按 版本策略 被标记为包含破坏性变更。这与 Authelia 的版本化政策一致Authelia 遵循语义化版本major表示破坏性变更、minor表示新功能、patch表示修复实验性特性Experimental Features不受稳定性承诺约束。Granular Authorization粒度化授权Granular Authorization 条目提出Authelia 已具备丰富的认证与授权体验但计划大幅提升管理员的自定义能力核心抓手是RFC 8176 Authentication Method Reference ValuesAMR 认证方法引用值——这一标准几乎被 OpenID Connect 1.0 与 SAML 2.0 等主流 IdP 协议普遍采用。文档用实例说明了 AMR 的价值管理员可以配置访问内部公司应用要求hwk或swk管理门户强制mfa且要求hwk与otp的组合任何 Authelia 管理门户至少要求mfa基础应用允许pwd而敏感资源要求更多因素等差异化策略同时继续复用既有的 Access Control Rules 或新兴的 OpenID Connect 1.0 Authorization Policies 来交付授权体验。该条目按五个阶段推进记录 AMR 值Record Authentication Methods Reference Values已完成v4.35.0最初为 OpenID Connect 1.0 而实现后续将扩展到通用授权与 SAML 2.0。从 AMR 值推导授权级别Derive Authorization Level已完成v4.39.0完全基于此前记录的 AMR 值推导授权级别为下一阶段铺路并简化关键逻辑。实现自定义 AMR 策略Implement Custom AMR Policies需设计needs-designv4.41.0允许管理员基于 RFC 8176 开发自定义策略例如自行决定每条规则所需的 Passkey 级别。自定义策略流程Custom Policy Flows需设计v4.41.0为支持自定义策略而构建前端流程。凭据注册Credential Registration需设计重点针对 WebAuthn因其可作登录方式优化注册时显示什么/不显示什么的决策过程。从源码侧可以印证 AMR 的落地方式。在 internal/authorization/amr.go 中AuthenticationMethodsReferences结构体把pwd、otp、pop、hwk、swk、sms、kba等 AMR 值映射为UsernameAndPassword、TOTP、Duo、WebAuthn等布尔标志并提供FactorKnowledge()知识因素、FactorPossession()持有因素、MultiFactorAuthentication()多因素判定、MultiChannelAuthentication()多通道判定等方法——这正是路线图所说用 AMR 值推导认证级别的底层实现。MarshalRFC8176()方法则将内部状态反向序列化为 RFC 8176 格式的 AMR 字符串数组用于写入 OIDC 的amr声明。完整取值与支持状态见 reference/guides/authentication-method-references.md 中的对照表mfa、mca、user、pin、kba、pwd、otp、pop、hwk、swk、sms受支持face、fpt、geo等标为不支持。Internationalization国际化/多语言支持Internationalization 条目指出国际化可以轻易在 Web 界面中实现并自动适配用户浏览器语言。其阶段包括Initial Implementation已完成v4.34.0为所有视图加入易于翻译的 Web 界面。Crowd Translation Service众包翻译已完成将仓库配置为可通过众包翻译平台翻译文档提示可参照 contributing/prologue/translations.md 贡献翻译。Picker语言选择器已完成v4.39.0为 Web 界面加入语言选择器属于按浏览器记忆的选择覆盖浏览器语言声明信息存储在浏览器 localStorage 中。Ongoing持续维护持续保持界面翻译更新。Multiple Domain Protection多域保护Multi-Domain Protection 条目开宗明义这是 Authelia 被用户请求最多的功能之一。它允许管理员用单个 Authelia 实例保护多个根域名但实现难度较大团队已将其列为优先事项。阶段规划如下Decide on a Method已完成已确定初始实现方式与 SSO 实现方式。Decide on a Session Library已完成团队决定弃用当前会话库改为完全在内部实现会话逻辑。Initial Implementation已完成v4.38.0采用基础 Cookie 实现用户需要在每个根域名分别登录暂不提供跨域 SSO。SSO Implementation规划中借助 OpenID Connect 1.0 等身份协议/框架参见 openid-connect-1.0-provider.md可以为用户透明地实现跨根域单点登录很可能与 OpenID Connect 1.0 Relying Party 支持同时落地。值得注意的是多域保护与 OIDC 的Multi-Issuer Configuration之间存在联动OIDC 初始设计早于多域保护被纳入考虑因此团队计划强制用户为每个希望提供 OIDC 服务的域名分别配置一个 Issuer。Control Panel / Dashboard for User Settings用户控制面板Dashboard / Control Panel for Users 条目认为让用户自助调整设置的面板是最具影响力的功能之一它将为大量用户侧功能铺路例如 WebAuthn 无密码认证的凭据注册、会话管理等。文档特别强调此面板是用户自管理个人设置与管理员管理系统设置的面板不是一回事。阶段包括Initial Implementation已完成v4.38.0提供控制面板管理当前所有设置并支持注册多个 WebAuthn 密钥用户可查看全部已注册设备并单独吊销。Password Reset密码重置已完成在知道当前密码的前提下提供重置方法。Language Option语言选项规划中允许用户覆盖浏览器检测语言。Session Management会话管理规划中允许用户查看并结束自己的会话。Control Panel / Dashboard and CLI for Administration Settings管理员控制面板与 CLIDashboard / Control Panel and CLI for Administrators 条目描述了管理员动态控制运行中的 Authelia的构想部分确定实施、部分可能不会实施可选地通过 CLI 或 UI 在运行时动态控制 Authelia。该功能将需要数据库内的设置存储以及少量传统的文件/环境变量设置。条目提出了两个核心设计原则Optional、Explicit、Modular可选、显式、模块化出于安全与灵活性管理员必须显式、刻意地启用动态控制默认保持静态配置以规避动态配置漏洞同时不剥夺用户钟爱的声明式配置。规划还要求支持额外缓解措施如外部防火墙仅允许特定网络地址或 ZTNA 身份访问并允许以下控制方式仅通过 CLI 或同时通过 CLI 控制通过 UI 控制可与门户同端口、不同端口甚至完全独立进程/主机。文档给出的设想配置片段摘自该条目{{ sitevar }}为文档站变量实际部署请以 configuration 文档 与 config.template.yml 为准server: address: tcp://:9091 administration: ## Explicitly enable Dynamic Configuration, either via CLI only or CLI and UI via enable_ui. enable: false ## Explicitly enable the Admin UI on this Authelia instance. If enable is configured another process could also be ## separately configured with this enabled. enable_ui: false ## Configure the listener address for the UI. If its exactly the same host and port component as above with a ## different path, listen on the same listener as above. If its exactly the same, error. address: tcp://:9092 ## URL enabling the button/link in the portal for the UI. url: https://auth-admin.example.com ## List of users who are allowed to view the admin UI. In addition to the groups. users: - john ## List of groups who are allowed to view the admin UI. In addition to the users. groups: - adminsAPI 设计长期来看该功能必须配备通过 OAuth 2.0 或用户会话授权的独立 API例如监听https://auth.example.com/admin时 API 走https://auth.example.com/admin/api/v1。Token 应支持粒度化访问权限、要求特殊 scope 与特定 audience 才有效。该条目的实施阶段包括Design Stage进行中、Initial Implementationv4.40.0、Segregation 设计要素允许 Admin UI 独立进程/端口/URL 运行或为最小化配置与主进程同端口v4.40.0、Session Management管理所有用户会话v4.40.0、OpenID Connect 1.0 Client ManagementWeb 前端管理客户端注册v4.40.0、Access Control Management管理访问控制规则规划中、User Management管理内部或 LDAP 认证后端的用户账号支持增删改规划中。Complete 阶段已完成或已收尾的功能Complete 条目表示此前积极开发、现已定稿或从路线图中移除的功能目前有两项。WebAuthnWebAuthn 条目解释了实现的紧迫背景Chrome 自 2022 年 8 月起移除了对 U2F API 的支持而 WebAuthn 是 FIDO U2F 协议的现代演进二者非常相似WebAuthn 还包含向后兼容的 FIDO AppID 扩展允许已注册的 U2F 设备继续用于认证。其阶段与关键 WebAuthn 设置默认值如下阶段状态版本Initial Implementation以 WebAuthn 替代 FIDO U2F 并保持向后兼容已完成v4.34.0Multi Device Registration多设备注册已完成v4.38.0Platform Authenticator平台认证器如 Windows Hello、TouchID、FaceID、Android Security Key已完成v4.39.0Passkeys注册 Passkey立即可作 2FA 凭据后续用于无密码登录已完成v4.39.0Passwordless Login无密码登录已完成v4.39.0初始实现中的四个 WebAuthn 设置默认值均可配置为Conveyancing Preference证明偏好默认indirect可询问用户是否允许采集 AAGUID类似型号编号的 GUID将存入 SQL 存储User Verification Requirement用户验证要求默认preferred可要求浏览器提示用户输入 PIN 或其他验证Resident Key Requirement常驻密钥要求默认discouraged与无密码登录阶段相关Authenticator Attachment认证器附着方式默认cross-platform与平台认证器阶段相关。WebAuthn 相关源码实现位于 internal/webauthn注册与登录处理器见 internal/handlers 下的handler_register_webauthn.go、handler_sign_webauthn.go等文件。Kubernetes DocumentationKubernetes Documentation 条目表示虽然已存在部分 Kubernetes 文档且不少用户已成功部署但仍需更完善的文档。其阶段包括Integration Documentation已完成提供通用的 integration/kubernetes/introduction.md 集成文档。Helm Chart已完成开发并发布 Helm Chart 以简化 Kubernetes 部署该 Chart 目前处于预发布状态但已相对完整距 v1 仅剩少量事项。Kustomize已放弃因社区需求极低、在 Kubernetes 生态中不流行相关文档仅作为示例保留。总结如何跟进 Authelia 的路线图Authelia 的路线图体现了三个鲜明特点公开透明所有规划对外共享版本号为预估且欢迎反馈纠正、分阶段推进每个功能拆解为带版本标记的实施阶段便于社区验证与追踪、以安全为先OIDC 以 beta 形式渐进落地、动态管理默认关闭、实验性特性受版本策略约束。对于使用者而言可以据此路线图做出更合理的升级与集成决策需要 SSO/联邦能力时优先关注 OpenID Connect 1.0 Provider 的 Beta 8v4.40.0 进行中与 Beta 9 规划参考 provider 配置 和 clients 配置需要精细授权时关注 Granular Authorization 的 v4.41.0 自定义 AMR 策略阶段AMR 支持表见 reference/guides/authentication-method-references.md需要多域名统一保护时关注 Multi-Domain Protection 的 SSO Implementation 阶段及其与 OIDC Relying Party 的联动部署在 Kubernetes 时直接使用已完成的 Helm Chart 相关文档。由于路线图条目中的版本号可能滞后于实际进度最准确的状态始终是仓库中的源码与 integration 文档 本身。【免费下载链接】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 Connect 到多域保护的产品规划与实现进展
Authelia 路线图全解读从 OpenID Connect 到多域保护的产品规划与实现进展【免费下载链接】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 官方文档中的路线图引言Prologue展开系统梳理了 Authelia 团队对产品未来的公开规划包括处于 Planning规划、Active进行中与 Complete已完成三个阶段的全部功能条目以及每个条目背后的设计思路、阶段划分与版本落地情况。读完本文你将完整掌握 Authelia 各核心功能OpenID Connect 1.0 Provider、粒度化授权、多域保护、用户/管理员控制面板、WebAuthn 等的演进脉络并能借助仓库中的源码、配置样例与参考指南深入验证每一项规划的实际实现状态。路线图的定位与阅读原则路线图引言docs/content/roadmap/prologue/introduction.md首先交代了 Authelia 团队的背景Authelia 团队由 3 名分布在全球的开发者组成利用业余时间持续改进 Authelia并基于一份对外公开的路线图来确定优先级以此保持透明度。团队一方面尽可能平衡新功能与改进另一方面必须投入精力完成维护任务将未解决问题open issues积压控制在一个合理水平。文档同时鼓励社区贡献者通过 Matrix 联系团队共同分享想法与计划。在阅读路线图时有一条重要提醒必须留意路线图条目中列出的版本号除非被标注为已完成completed否则都是预估版本intended estimation。计划可能发生变化团队也可能忘记更新版本号如果读者发现版本号有误可以通过 GitHub Discussion 或聊天渠道反馈。从源码结构看路线图文档体系位于 docs/content/roadmap/ 目录按planning/规划、active/进行中、complete/已完成、prologue/引言四个子目录组织每个条目对应一篇独立的 Markdown 文档使用{{ roadmap-status stage... version... }}短代码标注阶段与目标版本。这种状态徽章式的组织方式让社区可以直观地追踪每个功能的推进情况。Planning 阶段处于早期规划的功能处于 Planning 阶段的功能计划实施但仍处于非常早期的规划阶段目前包含两项都与让 Authelia 作为身份提供者IdP之外的角色参与更多生态相关。OpenID Connect 1.0 Relying Party依赖方OpenID Connect 1.0 Relying Party 条目指出Relying PartyRP角色通常被描述为客户端RP 依赖某个 OpenID Connect 1.0 Provider 来获取认证与授权信息把校验工作委托给 Provider。该条目按三个子主题拆分了设计思路Anchoring Implementation账户锚定为了让 RP 模式可用用户必须能把其 Provider 账号锚定到 Authelia 账号上。从文档描述推断较可能的实现是用户需先以满足two_factor策略的认证级别登录然后点击一个引导链接完成 onboard。账户之间将很可能通过成对pairwise的iss与sub声明即 issuer 与 subject identifier建立关联。文档还链接了 integration/openid-connect/frequently-asked-questions.md 中关于如何在应用中把用户账号与 Authelia 的 OpenID Connect 1.0 响应关联起来的 FAQ用以解释选择这两个声明的理由。Authorization Implementation授权实现授权时对用户的识别同样会使用此前锚定的成对iss与sub声明。从交互形态看这一功能很可能看起来与 Login with Passkey 按钮类似并提供一定的布局定制能力单独展示、放入菜单、或两者组合。Authentication Methods Reference Values认证方法引用值文档设想理论上可以结合 Granular Authorization粒度化授权用 AMR 值推导用户的有效认证级别并且很可能会以可选开启信任 Provideropt-in的设定来实现。关于 AMR 的具体含义可参考 reference/guides/authentication-method-references.md。Security Assertion Markup Language (SAML) 2.0 ProviderSAML 2.0 Provider 条目指出SAML 2.0 Provider 实现与 OpenID Connect 1.0 Provider 有诸多相同收益但面向的是支持 SAML 而非 OIDC 的客户端。目前该条目只有一个进行中的阶段Decide On a Library选定依赖库。文档强调市面上可用的成熟库不多且 SAML 2.0 基于 XML 的协议设计存在许多陷阱团队需要非常谨慎地评估所有选项。Active 阶段正在优先推进的功能Active 条目是正在积极开发、属于发展方向优先级的项目目前包含 6 项。以下逐项展开。OpenID Connect 1.0 ProviderOpenID Connect 1.0 Provider 是路线图中体量最大、粒度最细的条目。团队决定将 OAuth 2.0 与 OpenID Connect 1.0 以beta 特性形式实现虽然相对稳定但随着规范各环节的逐步落实可能不可避免地出现偶发破坏性变更因此建议使用该特性时比多数特性更谨慎。OIDC 及其相关端点默认不启用必须显式配置 OpenID Connect 1.0 Provider Configuration 与 OpenID Connect 1.0 Registered Clients 两个配置节才会生效。由于 OIDC尤其 Provider 角色相当复杂团队刻意以 beta 形式、并借助深思熟虑的路线图推进避免安全问题。OpenID Certified™Authelia 已通过 OpenID 认证符合 OpenID Connect 协议规范。认证详情见 integration/openid-connect/introduction.md 中的 OpenID Certified 章节该条目按 Beta 1 至 Beta 9 及 General Availability正式可用划分实施阶段每个阶段标注了落地版本阶段状态版本核心内容Beta 1已完成v4.29.0用户同意User Consent、授权码流程Authorization Code Flow、OIDC Discovery、RS256 签名策略、按客户端限制 scope/grant type/response type、按客户端授权策略1FA/2FA、合法重定向 URI 白名单、机密客户端Confidential ClientBeta 2已完成v4.30.0Userinfo 端点、参数熵、Token/Code 有效期、客户端调试消息、客户端 Audience、公共客户端Public ClientBeta 3已完成v4.34.0RFC 7636 PKCE授权码流程、preferred_username声明替代sub发送用户名Beta 4已完成v4.35.0持久化存储Token、可审计信息、subject 到用户映射、不透明 UUID v4 subject 标识符、pairwise/plain subject 类型采用 pairwise 示例方法 3、sub/amr/azp/client_id声明、CORS 支持Beta 5已完成v4.37.0X509 证书链支持的 JWK、客户端密钥哈希、按客户端的 Consent 模式Explicit/Implicit/Pre-ConfiguredBeta 6已完成v4.38.0RFC 9068 JWT Profile、RFC 9126 PAR、RFC 9207 Issuer Identification、RFC 6750 Bearer Token、JARM、JWT Token Inspection、RFC 7523client_secret_jwt/private_key_jwt、按客户端 PKCE 策略与 Token 有效期、Client Credentials Grant、多 Issuer JWKRS/PS/ES 系列、Client RBAC: Users and GroupsBeta 7已完成v4.39.0Prompt/Display/Claims 处理、自定义 Claims 策略、属性映射、自定义 Scopes、RFC 8628 设备授权流、JWE、Client RBAC: Networks同时包含破坏性变更默认 ID Token 声明调整、移除遗留端点Beta 8进行中v4.40.0存储内配置JWK 轮换、Multi-Issuer Configuration、基于规范的动态客户端注册authelia_dcrt_*、CLI 注册、YAML 导入、随机盐/加密胡椒化客户端凭证、Subject SectoringPPID、Sector Identifier 校验破坏性变更包括移除明文密码HMAC 类客户端认证方法除外与 Consent 策略重构Beta 9规划中—OpenID Connect Session Management、Back-Channel Logout、Front-Channel Logout、RP-Initiated Logout、CIBAGA规划中—对已实现特性提供官方稳定性保证此外条目还列出了一些**杂项Miscellaneous**规划Multi-Issuer Configuration计划中的破坏性变更要求每个需要提供 OIDC 服务的域名配置一个 Issuer彼此是完全独立的逻辑单元、OAuth 2.0 Authorization Server MetadataRFC 8414已完成于 v4.34.0、OAuth 2.0 Token ExchangeRFC 8693、动态客户端注册与注册管理协议、OIDC FAPI 2.0 安全配置文件进行中等。需要特别说明的是Beta 7 与 Beta 8 均按 版本策略 被标记为包含破坏性变更。这与 Authelia 的版本化政策一致Authelia 遵循语义化版本major表示破坏性变更、minor表示新功能、patch表示修复实验性特性Experimental Features不受稳定性承诺约束。Granular Authorization粒度化授权Granular Authorization 条目提出Authelia 已具备丰富的认证与授权体验但计划大幅提升管理员的自定义能力核心抓手是RFC 8176 Authentication Method Reference ValuesAMR 认证方法引用值——这一标准几乎被 OpenID Connect 1.0 与 SAML 2.0 等主流 IdP 协议普遍采用。文档用实例说明了 AMR 的价值管理员可以配置访问内部公司应用要求hwk或swk管理门户强制mfa且要求hwk与otp的组合任何 Authelia 管理门户至少要求mfa基础应用允许pwd而敏感资源要求更多因素等差异化策略同时继续复用既有的 Access Control Rules 或新兴的 OpenID Connect 1.0 Authorization Policies 来交付授权体验。该条目按五个阶段推进记录 AMR 值Record Authentication Methods Reference Values已完成v4.35.0最初为 OpenID Connect 1.0 而实现后续将扩展到通用授权与 SAML 2.0。从 AMR 值推导授权级别Derive Authorization Level已完成v4.39.0完全基于此前记录的 AMR 值推导授权级别为下一阶段铺路并简化关键逻辑。实现自定义 AMR 策略Implement Custom AMR Policies需设计needs-designv4.41.0允许管理员基于 RFC 8176 开发自定义策略例如自行决定每条规则所需的 Passkey 级别。自定义策略流程Custom Policy Flows需设计v4.41.0为支持自定义策略而构建前端流程。凭据注册Credential Registration需设计重点针对 WebAuthn因其可作登录方式优化注册时显示什么/不显示什么的决策过程。从源码侧可以印证 AMR 的落地方式。在 internal/authorization/amr.go 中AuthenticationMethodsReferences结构体把pwd、otp、pop、hwk、swk、sms、kba等 AMR 值映射为UsernameAndPassword、TOTP、Duo、WebAuthn等布尔标志并提供FactorKnowledge()知识因素、FactorPossession()持有因素、MultiFactorAuthentication()多因素判定、MultiChannelAuthentication()多通道判定等方法——这正是路线图所说用 AMR 值推导认证级别的底层实现。MarshalRFC8176()方法则将内部状态反向序列化为 RFC 8176 格式的 AMR 字符串数组用于写入 OIDC 的amr声明。完整取值与支持状态见 reference/guides/authentication-method-references.md 中的对照表mfa、mca、user、pin、kba、pwd、otp、pop、hwk、swk、sms受支持face、fpt、geo等标为不支持。Internationalization国际化/多语言支持Internationalization 条目指出国际化可以轻易在 Web 界面中实现并自动适配用户浏览器语言。其阶段包括Initial Implementation已完成v4.34.0为所有视图加入易于翻译的 Web 界面。Crowd Translation Service众包翻译已完成将仓库配置为可通过众包翻译平台翻译文档提示可参照 contributing/prologue/translations.md 贡献翻译。Picker语言选择器已完成v4.39.0为 Web 界面加入语言选择器属于按浏览器记忆的选择覆盖浏览器语言声明信息存储在浏览器 localStorage 中。Ongoing持续维护持续保持界面翻译更新。Multiple Domain Protection多域保护Multi-Domain Protection 条目开宗明义这是 Authelia 被用户请求最多的功能之一。它允许管理员用单个 Authelia 实例保护多个根域名但实现难度较大团队已将其列为优先事项。阶段规划如下Decide on a Method已完成已确定初始实现方式与 SSO 实现方式。Decide on a Session Library已完成团队决定弃用当前会话库改为完全在内部实现会话逻辑。Initial Implementation已完成v4.38.0采用基础 Cookie 实现用户需要在每个根域名分别登录暂不提供跨域 SSO。SSO Implementation规划中借助 OpenID Connect 1.0 等身份协议/框架参见 openid-connect-1.0-provider.md可以为用户透明地实现跨根域单点登录很可能与 OpenID Connect 1.0 Relying Party 支持同时落地。值得注意的是多域保护与 OIDC 的Multi-Issuer Configuration之间存在联动OIDC 初始设计早于多域保护被纳入考虑因此团队计划强制用户为每个希望提供 OIDC 服务的域名分别配置一个 Issuer。Control Panel / Dashboard for User Settings用户控制面板Dashboard / Control Panel for Users 条目认为让用户自助调整设置的面板是最具影响力的功能之一它将为大量用户侧功能铺路例如 WebAuthn 无密码认证的凭据注册、会话管理等。文档特别强调此面板是用户自管理个人设置与管理员管理系统设置的面板不是一回事。阶段包括Initial Implementation已完成v4.38.0提供控制面板管理当前所有设置并支持注册多个 WebAuthn 密钥用户可查看全部已注册设备并单独吊销。Password Reset密码重置已完成在知道当前密码的前提下提供重置方法。Language Option语言选项规划中允许用户覆盖浏览器检测语言。Session Management会话管理规划中允许用户查看并结束自己的会话。Control Panel / Dashboard and CLI for Administration Settings管理员控制面板与 CLIDashboard / Control Panel and CLI for Administrators 条目描述了管理员动态控制运行中的 Authelia的构想部分确定实施、部分可能不会实施可选地通过 CLI 或 UI 在运行时动态控制 Authelia。该功能将需要数据库内的设置存储以及少量传统的文件/环境变量设置。条目提出了两个核心设计原则Optional、Explicit、Modular可选、显式、模块化出于安全与灵活性管理员必须显式、刻意地启用动态控制默认保持静态配置以规避动态配置漏洞同时不剥夺用户钟爱的声明式配置。规划还要求支持额外缓解措施如外部防火墙仅允许特定网络地址或 ZTNA 身份访问并允许以下控制方式仅通过 CLI 或同时通过 CLI 控制通过 UI 控制可与门户同端口、不同端口甚至完全独立进程/主机。文档给出的设想配置片段摘自该条目{{ sitevar }}为文档站变量实际部署请以 configuration 文档 与 config.template.yml 为准server: address: tcp://:9091 administration: ## Explicitly enable Dynamic Configuration, either via CLI only or CLI and UI via enable_ui. enable: false ## Explicitly enable the Admin UI on this Authelia instance. If enable is configured another process could also be ## separately configured with this enabled. enable_ui: false ## Configure the listener address for the UI. If its exactly the same host and port component as above with a ## different path, listen on the same listener as above. If its exactly the same, error. address: tcp://:9092 ## URL enabling the button/link in the portal for the UI. url: https://auth-admin.example.com ## List of users who are allowed to view the admin UI. In addition to the groups. users: - john ## List of groups who are allowed to view the admin UI. In addition to the users. groups: - adminsAPI 设计长期来看该功能必须配备通过 OAuth 2.0 或用户会话授权的独立 API例如监听https://auth.example.com/admin时 API 走https://auth.example.com/admin/api/v1。Token 应支持粒度化访问权限、要求特殊 scope 与特定 audience 才有效。该条目的实施阶段包括Design Stage进行中、Initial Implementationv4.40.0、Segregation 设计要素允许 Admin UI 独立进程/端口/URL 运行或为最小化配置与主进程同端口v4.40.0、Session Management管理所有用户会话v4.40.0、OpenID Connect 1.0 Client ManagementWeb 前端管理客户端注册v4.40.0、Access Control Management管理访问控制规则规划中、User Management管理内部或 LDAP 认证后端的用户账号支持增删改规划中。Complete 阶段已完成或已收尾的功能Complete 条目表示此前积极开发、现已定稿或从路线图中移除的功能目前有两项。WebAuthnWebAuthn 条目解释了实现的紧迫背景Chrome 自 2022 年 8 月起移除了对 U2F API 的支持而 WebAuthn 是 FIDO U2F 协议的现代演进二者非常相似WebAuthn 还包含向后兼容的 FIDO AppID 扩展允许已注册的 U2F 设备继续用于认证。其阶段与关键 WebAuthn 设置默认值如下阶段状态版本Initial Implementation以 WebAuthn 替代 FIDO U2F 并保持向后兼容已完成v4.34.0Multi Device Registration多设备注册已完成v4.38.0Platform Authenticator平台认证器如 Windows Hello、TouchID、FaceID、Android Security Key已完成v4.39.0Passkeys注册 Passkey立即可作 2FA 凭据后续用于无密码登录已完成v4.39.0Passwordless Login无密码登录已完成v4.39.0初始实现中的四个 WebAuthn 设置默认值均可配置为Conveyancing Preference证明偏好默认indirect可询问用户是否允许采集 AAGUID类似型号编号的 GUID将存入 SQL 存储User Verification Requirement用户验证要求默认preferred可要求浏览器提示用户输入 PIN 或其他验证Resident Key Requirement常驻密钥要求默认discouraged与无密码登录阶段相关Authenticator Attachment认证器附着方式默认cross-platform与平台认证器阶段相关。WebAuthn 相关源码实现位于 internal/webauthn注册与登录处理器见 internal/handlers 下的handler_register_webauthn.go、handler_sign_webauthn.go等文件。Kubernetes DocumentationKubernetes Documentation 条目表示虽然已存在部分 Kubernetes 文档且不少用户已成功部署但仍需更完善的文档。其阶段包括Integration Documentation已完成提供通用的 integration/kubernetes/introduction.md 集成文档。Helm Chart已完成开发并发布 Helm Chart 以简化 Kubernetes 部署该 Chart 目前处于预发布状态但已相对完整距 v1 仅剩少量事项。Kustomize已放弃因社区需求极低、在 Kubernetes 生态中不流行相关文档仅作为示例保留。总结如何跟进 Authelia 的路线图Authelia 的路线图体现了三个鲜明特点公开透明所有规划对外共享版本号为预估且欢迎反馈纠正、分阶段推进每个功能拆解为带版本标记的实施阶段便于社区验证与追踪、以安全为先OIDC 以 beta 形式渐进落地、动态管理默认关闭、实验性特性受版本策略约束。对于使用者而言可以据此路线图做出更合理的升级与集成决策需要 SSO/联邦能力时优先关注 OpenID Connect 1.0 Provider 的 Beta 8v4.40.0 进行中与 Beta 9 规划参考 provider 配置 和 clients 配置需要精细授权时关注 Granular Authorization 的 v4.41.0 自定义 AMR 策略阶段AMR 支持表见 reference/guides/authentication-method-references.md需要多域名统一保护时关注 Multi-Domain Protection 的 SSO Implementation 阶段及其与 OIDC Relying Party 的联动部署在 Kubernetes 时直接使用已完成的 Helm Chart 相关文档。由于路线图条目中的版本号可能滞后于实际进度最准确的状态始终是仓库中的源码与 integration 文档 本身。【免费下载链接】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），仅供参考