Authelia 与 Donetick 集成指南通过 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本文是一份针对 Donetick开源的自托管任务/待办事项管理应用与 Authelia 内置 OpenID Connect 1.0 Provider 的完整集成实操指南。文章以官方集成文档 docs/content/integration/openid-connect/clients/donetick/index.md 为主体结合 客户端配置参考 与 OpenID Connect 1.0 集成总览覆盖 Authelia 注册客户端配置、Donetick 三种配置方式环境变量、Docker Compose、配置文件以及已知限制。读完本文你将能在自托管环境中把 Donetick 的登录流程完全接入 Authelia实现统一身份认证与多因素认证MFA保护。测试版本本指南在以下版本组合上验证通过Autheliav4.39.24Donetickv0.1.53不同版本的配置项可能与本文存在差异升级时请以当前版本的官方文档为准。开始之前在配置任何 OpenID Connect 1.0 注册客户端之前有几个关键要素需要先了解清楚它们直接影响后续配置的正确性与安全性。client_id 的要求必须全局唯一每个注册客户端的client_id必须与仓库中其他客户端不同。字符集限制只能包含 RFC3986 Unreserved Characters即大小写字母、数字以及-、.、_、~不能包含冒号、斜杠、等保留字符。长度限制不能超过 100 个字符。生产建议本指南使用donetick仅为便于阅读演示。生产环境建议生成 64 位随机字符串参见 FAQ 中 如何生成 client identifier 或 client secret。client_secret 的要求本指南中的insecure_secret仅为演示用途绝对不要在生产环境使用应通过 Authelia 的随机密码生成器生成强随机值。client_secret在 Authelia 配置中支持明文存储但该行为已废弃未来不保证继续支持。强烈推荐在配置中存储哈希后的值见下文 Authelia 配置示例。当 secret 以哈希形式存储时如果哈希计算成本work factor过高可能导致客户端请求超时。相关调优方法见 FAQ 中的 Tuning the work factors 章节。配置范围说明本指南中的 Authelia 配置片段仅包含注册客户端部分。你必须同时在identity_providers.oidc下配置 Provider 级别的必需项如 issuer 相关设置完整说明见 OpenID Connect 1.0 Provider 配置指南。假设条件本示例基于以下假设你可以按实际环境替换项目值应用根 URLDonetickhttps://donetick.example.com/Authelia 根 URLhttps://auth.example.com/Client IDdonetickClient Secretinsecure_secret其中example.com为你的主域名auth为 Authelia 子域名。下文所有 URL 均按此约定书写。配置 Authelia以下 YAML 是用于将 Donetick 注册为 Authelia OpenID Connect 1.0 客户端的示例配置与上述应用示例配合工作identity_providers: oidc: ## The other portions of the mandatory OpenID Connect 1.0 configuration go here. ## See: https://www.authelia.com/c/oidc clients: - client_id: donetick client_name: Donetick client_secret: $pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng # The digest of insecure_secret. public: false authorization_policy: two_factor require_pkce: false pkce_challenge_method: redirect_uris: - https://donetick.example.com/auth/oauth2 scopes: - openid - profile - email access_token_signed_response_alg: none userinfo_signed_response_alg: none token_endpoint_auth_method: client_secret_basic各配置项说明下面对示例中每个字段的作用做逐项解析更完整的可选配置清单见 OpenID Connect 1.0 Clients 配置文档。client_id客户端标识符必须与 Donetick 侧配置的DT_OAUTH2_CLIENT_ID完全一致。client_name在 Authelia 登录/授权界面中显示的应用友好名称默认与client_id相同。client_secretAuthelia 与 Donetick 之间的共享密钥此处存储的是insecure_secret的 PBKDF2-SHA512 哈希值$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng。若使用哈希存储请确保 Donetick 侧配置的是原始明文secret。public: false将 Donetick 声明为机密confidential客户端类型即它能安全保存凭证可在 Token 端点进行客户端认证。参见 RFC6749 Section 2.1。authorization_policy: two_factor该客户端的授权策略可选one_factor、two_factor或 Provider 级authorization_policies中自定义的策略。此策略仅作用于 Authorization Request与访问控制规则Access Control Rules是两套独立机制。设置为two_factor意味着用户登录 Donetick 时必须完成第二因素认证。require_pkce: false与pkce_challenge_method: 本客户端不强制使用 PKCEProof Key for Code Exchange。由于 Donetick 采用client_secret_basic进行令牌端点认证且为机密客户端PKCE 并非必需若应用支持可将其改为S256以增强授权码防拦截能力。redirect_uris回调 URI 白名单Donetick 的回调地址为https://donetick.example.com/auth/oauth2。URI 区分大小写且必须为http或https方案未列入白名单的回调将被 Authelia 拒绝。scopes允许该客户端请求的 scope 列表此处为openid、profile、email与 Donetick 侧配置保持一致。scope 定义详见 OpenID Connect 1.0 Claims 指南。access_token_signed_response_alg: none与userinfo_signed_response_alg: none访问令牌与 UserInfo 响应均以明文 JSON 形式返回不进行 JWT 签名。绝大多数客户端不支持签名令牌Donetick 同样按默认 JSON 响应处理。token_endpoint_auth_method: client_secret_basic客户端在 Token 端点使用 HTTP Basic 认证方式提交client_id/client_secret。这也是机密客户端在规范要求下的默认值。关于端点 URLDonetick 配置中需要填写三个 Authelia 端点地址。若应用不支持 OpenID Connect Discovery自动发现可按下表手动填写。这些端点路径在 集成总览 中有完整记录并可通过https://auth.example.com/.well-known/openid-configuration动态发现端点URL授权端点Authorizationhttps://auth.example.com/api/oidc/authorization令牌端点Tokenhttps://auth.example.com/api/oidc/token用户信息端点UserInfohttps://auth.example.com/api/oidc/userinfo配置 DonetickDonetick 支持两种配置方式环境变量或配置文件。你可以任选其一二者效果等价。方式一标准环境变量.env在 Donetick 的环境文件如.env中配置以下变量DT_OAUTH2_NAMEAuthelia DT_OAUTH2_CLIENT_IDdonetick DT_OAUTH2_CLIENT_SECRETinsecure_secret DT_OAUTH2_SCOPEopenid profile email DT_OAUTH2_AUTH_URLhttps://auth.example.com/api/oidc/authorization DT_OAUTH2_TOKEN_URLhttps://auth.example.com/api/oidc/token DT_OAUTH2_INFO_URLhttps://auth.example.com/api/oidc/userinfo DT_OAUTH2_REDIRECT_URLhttps://donetick.example.com/auth/oauth2各变量与 Authelia 配置的对应关系DT_OAUTH2_NAMEOAuth2 提供方的显示名称将出现在 Donetick 登录页此处为Authelia。DT_OAUTH2_CLIENT_ID/DT_OAUTH2_CLIENT_SECRET必须与 Authelia 注册的client_id及原始明文 secret 一致。DT_OAUTH2_SCOPE空格分隔的 scope 列表需与 Authelia 侧scopes一致。DT_OAUTH2_AUTH_URL/DT_OAUTH2_TOKEN_URL/DT_OAUTH2_INFO_URL即上表三个端点。DT_OAUTH2_REDIRECT_URL必须与 Autheliaredirect_uris中的条目完全一致https://donetick.example.com/auth/oauth2。方式二Docker Compose在compose.yml的 Donetick 服务中通过environment注入同样的配置services: donetick: environment: DT_OAUTH2_NAME: Authelia DT_OAUTH2_CLIENT_ID: donetick DT_OAUTH2_CLIENT_SECRET: insecure_secret DT_OAUTH2_SCOPES: openid profile email DT_OAUTH2_AUTH_URL: https://auth.example.com/api/oidc/authorization DT_OAUTH2_TOKEN_URL: https://auth.example.com/api/oidc/token DT_OAUTH2_USER_INFO_URL: https://auth.example.com/api/oidc/userinfo DT_OAUTH2_REDIRECT_URL: https://donetick.example.com/auth/oauth2注意Docker Compose 示例中的变量名与标准.env略有差异如DT_OAUTH2_SCOPES复数、DT_OAUTH2_USER_INFO_URL请以实际使用的 Donetick 版本支持的变量名为准。方式三配置文件selfhosted.ymlDonetick 也支持通过 YAML 配置文件启用 OAuth2结构与环境变量一一对应oauth2: name: Authelia client_id: donetick client_secret: insecure_secret scopes: - openid - profile - email auth_url: https://auth.example.com/api/oidc/authorization token_url: https://auth.example.com/api/oidc/token user_info_url: https://auth.example.com/api/oidc/userinfo redirect_url: https://donetick.example.com/auth/oauth2此处的scopes以 YAML 列表形式书写语义与.env中的空格分隔字符串相同。登录流程与原理配置完成后Donetick 用户点击登录时将走标准的 OpenID Connect 1.0授权码流程Authorization Code FlowDonetick 将用户重定向至 Authelia 授权端点https://auth.example.com/api/oidc/authorization携带client_iddonetick与回调地址等参数。用户在 Authelia 门户完成认证。由于authorization_policy为two_factor需要密码加第二因素TOTP / WebAuthn / Duo 等。Authelia 将授权码通过redirect_uri/auth/oauth2返回给 Donetick。Donetick 以client_secret_basic方式在令牌端点https://auth.example.com/api/oidc/token用授权码换取 Access Token 与 ID Token。Donetick 调用 UserInfo 端点https://auth.example.com/api/oidc/userinfo获取profile、email等声明用于建立本地会话与用户资料。从源码结构看上述三个端点分别对应 Authelia 中的授权、令牌与用户信息处理器见 internal/handlers/handler_oauth2_authorization.go、handler_oauth2_token.go 与 handler_oauth2_oidc_userinfo.go端点路径与发现元数据在 internal/handlers/handler_oauth2_wellknown.go 等实现中维护。已知限制Android App需要特别注意的是Donetick 官方 Android 应用截至 v0.1.34无法在自托管 Donetick 实例上使用 OpenID 登录相关问题已在 Donetick 项目 issue #268 中跟踪。如果移动端登录对你是刚需请先确认所使用的 Donetick 版本是否已修复该问题再决定是否启用 OAuth2否则建议保留本地账号登录作为兜底。安全加固建议基于 Authelia 的客户端配置能力针对 Donetick 集成可以进一步强化替换演示凭据将insecure_secret换成强随机值并在 Authelia 配置中存储其 PBKDF2 哈希生成方法参见 如何生成 client identifier 或 client secret。启用 PKCE将客户端配置改为require_pkce: true且pkce_challenge_method: S256可显著缓解授权码拦截攻击仅当 Donetick 版本支持 PKCE 时有效。收紧授权策略如需让 Donetick 仅凭密码即可登录可将authorization_policy调为one_factor默认two_factor更安全。关注声明绑定部分第三方应用使用email、preferred_username等可变声明绑定本地账号而不是规范推荐的不变sub与iss声明存在潜在的越权风险。集成后应确认 Donetick 的账号绑定逻辑并保证sub声明唯一稳定。延伸阅读OpenID Connect 1.0 集成总览端点实现、授权码流程、签名算法与安全特性PKCE、PAR、JARM 等的完整说明。OpenID Connect 1.0 Clients 配置参考本文所述全部客户端配置项的完整字段、默认值与约束。OpenID Connect 1.0 Provider 配置指南Provider 级配置issuer、生命周期、授权策略、密钥等。OpenID Connect 1.0 常见问题client secret 哈希、工作因子调优、授权码流程等 FAQ。OpenID Connect 1.0 Claims 指南openid、profile、email等 scope 的具体声明定义。【免费下载链接】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），仅供参考