Authelia 集成 Tandoor基于 OpenID Connect 1.0 的 SSO 单点登录完整配置指南【免费下载链接】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 官方集成指南为基础详细介绍如何将开源食谱管理应用 Tandoor 接入 Authelia 的 OpenID Connect 1.0 Provider实现统一身份认证与多因素登录。你将掌握 Authelia 侧 OIDC 客户端的完整注册配置含各参数含义、Tandoor 侧基于 django-allauth 的环境变量配置方法.env与 Docker Compose 两种形态以及授权码流程、PKCE、客户端认证方式等底层原理可直接套用到自己的生产环境。测试版本Tested Versions本文档对应的集成方案经过以下版本组合的验证Autheliav4.39.24Tandoorv1.5.34该集成由社区维护support level 为 community官方会持续更新。实际部署时建议使用不低于上述版本的发行版并以当前仓库 docs/content/integration/openid-connect/clients/tandoor/index.md 中的最新内容为准。前提假设Assumptions本示例基于以下环境假设展开后续所有配置均围绕这些值项目值Tandoor 应用根地址https://tandoor.example.com/Authelia 根地址https://auth.example.com/Client IDtandoorClient Secretinsecure_secret上述 URL 中的example.com与auth在官方文档中是可通过站点变量sitevar自动替换的占位值{{ sitevar namedomain nojsexample.com }}对应主域名{{ sitevar namesubdomain-authelia nojsauth }}对应 Authelia 子域。阅读官方文档时这些变量会根据读者偏好自动填充本文为便于展示统一使用example.com与auth作为示例值部署时请替换为你自己的域名。开始前的公共须知在动手配置前有几个 Authelia OIDC 客户端注册的通用要点需要先明确源自所有集成指南共用的 oidc-common 模板client_id的约束必须在所有客户端中全局唯一只能包含 RFC3986 未保留字符长度不超过 100 字符。指南中的tandoor仅为便于阅读的演示值生产环境强烈建议使用随机生成的长字符串推荐 64 个随机字符。client_secret的安全性示例中的insecure_secret仅用于演示绝对不能用于生产。建议使用 Authelia 提供的随机密码生成工具生成Authelia 配置中允许以明文存储 secret但该行为已被标记为弃用deprecated推荐存储为哈希形式详见下文 Authelia 配置中的$pbkdf2-sha512$...示例。配置完整性下文给出的 Authelia YAML 只包含 Tandoor 这一个客户端的注册片段你还必须按照 OpenID Connect 1.0 Provider 配置 完成 Provider 级别的必填配置如签发密钥、issuer 等。客户端还有大量可选参数lifespan、consent_mode、claims_policy等建议通读 OpenID Connect 1.0 Clients 配置文档 后按需调整。Authelia 端注册 Tandoor 为 OIDC 客户端在 Authelia 的configuration.yml中identity_providers.oidc.clients下注册 Tandooridentity_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: tandoor client_name: Tandoor 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://tandoor.example.com/accounts/oidc/authelia/login/callback/ scopes: - openid - profile - email response_types: - code grant_types: - authorization_code 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客户端唯一标识必须与 Tandoor 侧配置的client_id完全一致Tandoor 侧为tandoor。client_name展示名称仅用于 Authelia 管理界面与用户授权页面的可读性展示。client_secret客户端密钥。此处存放的是明文insecure_secret的 PBKDF2-SHA512 哈希摘要$pbkdf2-sha512$310000$...这是官方推荐的安全存储方式哈希代价因子过高时可能导致客户端超时可参考 FAQ 中的Tuning the work factors章节调整。public: false声明为机密客户端confidential client意味着它能够在 Token 端点进行客户端认证对应token_endpoint_auth_method的client_secret_basic。authorization_policy: two_factor该客户端的授权策略为双因素认证。Authelia 支持one_factor仅密码与two_factor密码 第二因素两种取值对应 Tandoor 登录时的安全强度要求。require_pkce: false不强制要求 PKCEProof Key for Code Exchange。由于 Tandoor 侧示例中启用了OAUTH_PKCE_ENABLED且本客户端是机密客户端、使用client_secret_basic认证可安全地保持关闭若你的场景希望强制 PKCE可设置为true。pkce_challenge_method: 留空表示不指定 PKCE 挑战方法。若启用 PKCE官方默认推荐S256见配置文档示例。redirect_uris授权回调地址白名单。必须与 Tandoor 的 django-allauth 回调路径完全一致https://tandoor.example.com/accounts/oidc/authelia/login/callback/注意路径末端的斜杠与authelia段对应下方 Tandoor 配置中的provider_id。scopes授权作用域。openid是 OIDC 必需作用域profile提供姓名、用户名等基础资料email提供邮箱地址Tandoor 用于匹配/创建本地账户。response_types: [code]仅支持授权码流程Authorization Code Flow这是 Web 应用最安全的流程。grant_types: [authorization_code]与response_types: [code]配套的授权类型。access_token_signed_response_alg: noneAccess Token 不进行 JWT 签名即返回不透明 Token。这是 Authelia 的默认行为详细介绍可参见 FAQ 中Why isnt the Access Token a JSON Web Token?。userinfo_signed_response_alg: noneUserInfo 端点以普通 JSON 而非签名 JWT 返回用户信息。token_endpoint_auth_method: client_secret_basicTandoor 在 Token 端点使用 HTTP Basic 认证携带客户端凭据对应 Tandoor 侧token_auth_method的设置二者必须匹配。Tandoor 端通过环境变量接入 AutheliaTandoor 基于 Django 的 django-allauth 实现第三方登录官方仅提供一种配置方式环境变量。为便于理解官方文档先给出了SOCIALACCOUNT_PROVIDERS环境变量的可读 JSON 格式{ openid_connect: { SCOPE: [openid, profile, email], OAUTH_PKCE_ENABLED: true, APPS: [ { provider_id: authelia, name: Authelia, client_id: tandoor, secret: insecure_secret, settings: { server_url: https://auth.example.com/.well-known/openid-configuration, token_auth_method: client_secret_basic } } ] } }字段对应关系如下provider_idauthelia该值直接决定回调 URL 路径中的authelia段与 Authelia 侧redirect_uris保持一致。client_id/secret必须与 Authelia 侧注册的客户端凭据一致演示值tandoor/insecure_secret。server_urlAuthelia 的 OpenID Connect Discovery 端点https://auth.example.com/.well-known/openid-configuration。Tandoor 通过它自动发现授权端点、Token 端点、UserInfo 端点、JWKS 等元数据对应 OpenID Connect 1.0 集成介绍 中列举的.well-known/openid-configuration与.well-known/oauth-authorization-server发现端点。token_auth_methodclient_secret_basic与 Authelia 侧token_endpoint_auth_method匹配。OAUTH_PKCE_ENABLED: trueTandoor 启用 PKCES256 挑战方法。注意即使 Authelia 侧require_pkce为falseTandoor 侧主动启用 PKCE 也是完全兼容的——PKCE 由客户端生成code_verifier并计算 SHA-256 摘要作为code_challengeAuthelia 均支持PKCE 已获 OpenID 官方认证详见 OpenID Connect 1.0 集成介绍 的 Support Chart。SCOPE与 Authelia 侧scopes一致请求openid、profile、email三个作用域。标准部署.env文件在 Tandoor 的.env中添加以下两个变量SOCIAL_PROVIDERSallauth.socialaccount.providers.openid_connect SOCIALACCOUNT_PROVIDERS{openid_connect:{SCOPE:[openid,profile,email],OAUTH_PKCE_ENABLED:true,APPS:[{provider_id:authelia,name:Authelia,client_id:tandoor,secret:insecure_secret,settings:{server_url:https://auth.example.com/.well-known/openid-configuration,token_auth_method:client_secret_basic}}]}}其中SOCIAL_PROVIDERS用于启用 django-allauth 的 OpenID Connect 后端SOCIALACCOUNT_PROVIDERS为压缩成单行的 JSON 配置与上文可读 JSON 等价注意 JSON 内部的双引号转义。Docker Compose 部署若使用 Docker Compose 编排 Tandoor在服务定义的environment中声明同样的两个变量services: tandoor: environment: SOCIAL_PROVIDERS: allauth.socialaccount.providers.openid_connect SOCIALACCOUNT_PROVIDERS: {openid_connect:{SCOPE:[openid,profile,email],OAUTH_PKCE_ENABLED:true,APPS:[{provider_id:authelia,name:Authelia,client_id:tandoor,secret:insecure_secret,settings:{server_url:https://auth.example.com/.well-known/openid-configuration,token_auth_method:client_secret_basic}}]}}配置完成后重启 Tandoor 容器登录页面即会出现Authelia社交登录入口。集成后的认证流程配置完成后一次完整的 Tandoor → Authelia 登录走的是标准的授权码流程Authorization Code Flow用户在 Tandoor 登录页点击Authelia社交登录按钮。Tandoor 根据 Discovery 文档获取 Authelia 的授权端点/api/oidc/authorization携带client_idtandoor、scopeopenid profile email、回调地址以及 PKCEcode_challengeS256重定向到 Authelia。用户完成 Authelia 侧认证。由于authorization_policy: two_factor此阶段会要求双因素验证。Authelia 校验通过后将授权码通过回调 URL 送回 Tandoor 的/accounts/oidc/authelia/login/callback/。Tandoor 携带授权码与code_verifier向 Authelia 的 Token 端点/api/oidc/token发起请求并使用client_secret_basic完成客户端认证。Authelia 返回 ID Token 与 Access TokenTandoor 再通过 UserInfo 端点/api/oidc/userinfo获取profile、email声明完成本地账户的创建/匹配与登录。以上各端点路径均为 Authelia 的标准实现完整端点清单含 JWKS、Introspection、Revocation、Pushed Authorization Request 等见 OpenID Connect 1.0 集成介绍 的 Endpoint Implementations 章节。生产环境注意事项务必更换演示凭据将client_id推荐 64 位随机字符串、client_secret推荐哈希存储而非明文以及示例域名全部替换为实际值并同步更新 Authelia 与 Tandoor 两侧配置。回调 URL 必须精确匹配Tandoor 侧provider_id: authelia决定了回调路径中的authelia段两侧不一致会导致授权回调被 Authelia 拒绝。token_auth_method与token_endpoint_auth_method必须一致本文统一使用client_secret_basic若改用client_secret_post或 JWT 断言方式需两端同步调整。Discovery 端点先行验证配置排障时可先直接访问https://auth.example.com/.well-known/openid-configuration确认 Authelia 的 OIDC 元数据可正常返回再检查 Tandoor 侧的变量格式尤其是 JSON 转义。PKCE 是加分项而非负担本示例中 Tandoor 主动启用 PKCE即使 Authelia 端未强制也能额外缓解授权码拦截类攻击建议保持开启。延伸阅读Authelia OpenID Connect 1.0 集成介绍协议支持范围、端点清单、算法与支持矩阵。OpenID Connect 1.0 Clients 配置文档客户端全部配置项含本文未展开的lifespan、consent_mode、claims_policy等。OpenID Connect 1.0 Provider 配置文档Provider 级必填配置与签发密钥设置。集成指南目录Authelia 支持的其他 OIDC 客户端集成示例。Tandoor 官方文档中的 Authentication / Allauth 章节提供了更多关于社交登录行为与账户绑定的细节Tandoor 侧配置随版本可能演进请以其官方文档为准。【免费下载链接】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），仅供参考