企业官网建设流程全解析

Authelia 与 Glitchtip 集成：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

本指南详细讲解如何将自托管错误跟踪平台Glitchtip接入 Authelia 的 OpenID Connect 1.0 Provider，实现统一身份认证与单点登录。你将掌握在 Authelia 侧注册机密型 OIDC 客户端（含授权码流程、作用域、PKCE 与签名算法等关键参数）的完整 YAML 写法，以及通过 Glitchtip 的 Django Admin Web GUI 完成社交应用（Social Application）配置的实操步骤，最终让用户借助 Authelia 的两步验证（Two-Factor）策略安全登录 Glitchtip。全文以仓库文档 docs/content/integration/openid-connect/clients/glitchtip/index.md 为主线，并结合仓库内的配置参考与源码文档进行深度展开。

集成概览与已验证版本

本集成属于 Authelia 官方 OpenID Connect 1.0 集成系列中的社区维护（community）级别方案，其验证版本如下：

以上版本为文档撰写时已验证的组合；其他版本大概率也可正常工作，但建议以你实际部署的 Authelia 版本对应的 OpenID Connect 1.0 集成介绍 为准。

集成前提与假设

本示例基于以下假设开展配置，请根据你的实际环境替换相应取值：

• 应用根 URL（Application Root URL）：https://glitchtip.{{< sitevar name="domain" nojs="example.com" >}}/（即 Glitchtip 实例地址）
• Authelia 根 URL：https://{{< sitevar name="subdomain-authelia" nojs="auth" >}}.{{< sitevar name="domain" nojs="example.com" >}}/（即 Authelia 实例地址，也是 OIDC Issuer）
• Client ID：glitchtip
• Client Secret：insecure_secret

原文档中部分取值（如域名）使用了站点变量（sitevar）自动替换机制，实际部署时请以你自己的域名替换example.com与子域名。此外，Glitchtip 侧的配置要求你已通过 Django Admin 创建超级用户（Super User），相关步骤可参考 Glitchtip 官方安装文档中的 Django Admin 章节。

配置前的通用注意事项（Before You Begin）

在动手配置 OIDC 注册客户端之前，仓库中的公共短代码模板 docs/layouts/_shortcodes/oidc-common.html 注入了一系列重要提示，它们是所有 OIDC 客户端集成的通用前置知识：

1. client_id必须全局唯一。本指南中的glitchtip仅为便于阅读与演示的可读性取值，不应直接用于生产环境，生产环境建议按 FAQ 指引生成 64 位随机字符的标识符（详见下文"生成安全的 Client ID 与 Client Secret"）。
2. client_id的字符约束：只能包含 RFC3986 Unreserved Characters）。
3. client_secret的演示值警告：insecure_secret仅用于演示，生产环境绝对不要使用；该字符串可以明文存储在 Authelia 配置中，但这一行为已被标记为弃用（deprecated），官方强烈推荐以哈希形式存储（详见下文"密钥哈希"小节）。
4. 必须补齐 Provider 基础配置：下面给出的 YAML 只是clients段落的示例，你还必须按照 OpenID Connect 1.0 Provider 配置指南 配置identity_providers.oidc下的其他必选项（如issuer_private_keys等）。

在 Authelia 中注册 Glitchtip 客户端

以下 YAML 是用于 Glitchtip 的 Authelia客户端配置示例，将其放入 Authelia 的configuration.yml中即可与本集成方案协同工作：

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: 'glitchtip' client_name: 'Glitchtip' 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://glitchtip.{{< sitevar name="domain" nojs="example.com" >}}/accounts/authelia/login/callback/' scopes: - 'openid' - 'email' - 'profile' 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/client_name：客户端唯一标识与显示名称。client_name默认与 ID 相同，此处显式设置为Glitchtip，会显示在 Authelia 的用户授权（Consent）界面中。
• client_secret（密钥哈希）：Authelia 与 Glitchtip 之间共享的机密，必须与 Glitchtip 侧配置的 Secret Key 完全一致。示例中的值为明文insecure_secret的 PBKDF2-SHA512 摘要（$pbkdf2-sha512$310000$...）。官方强烈推荐以哈希形式存储，因为配置中保存哈希后，即使配置文件泄露也不会直接暴露明文密钥。
• public: false：声明该客户端为机密型（confidential）客户端，即有能力保守凭证机密，这也是 Glitchtip 这类服务端应用的正确类型。client_secret在此类客户端上为必填。
• authorization_policy: 'two_factor'：对该客户端施加two_factor授权策略——用户登录 Glitchtip 时将被要求完成两步验证。可选值为one_factor、two_factor，或在 Provider 的authorization_policies中自定义的命名策略（详见 provider.md）。需注意该策略仅作用于 Authorization Request，不应与访问控制规则（Access Control Rules）混淆。
• require_pkce: false与pkce_challenge_method: ''：本示例未强制要求 Proof Key for Code Exchange（PKCE），也未强制指定挑战方法。若想启用，pkce_challenge_method可取plain或S256，其中S256被强烈推荐（若依赖方支持）；设置该方法等效于同时开启require_pkce。
• redirect_uris：授权后允许重定向回调的白名单，大小写敏感，且 scheme 必须是http或https。此处使用 Glitchtip 社交登录的回调路径/accounts/authelia/login/callback/（该路径由 Glitchtip 基于 django-allauth 的社交登录流程定义），不在列表中的回调将被 Authelia 判定为不安全而拒绝。
• scopes：允许该客户端请求的作用域：openid、email、profile。openid是 OIDC 必需作用域；email提供用户邮箱声明，profile提供用户资料声明，二者用于 Glitchtip 建立本地账号资料。作用域定义可参考 OIDC Claims 文档。
• response_types: ['code']：仅使用Authorization Code Flow（授权码流程）。这是官方推荐的最安全响应类型，也是 Glitchtip 实际使用的流程。
• grant_types: ['authorization_code']：仅允许authorization_code授权类型访问令牌端点。
• access_token_signed_response_alg: 'none'与userinfo_signed_response_alg: 'none'：指明访问令牌与 UserInfo 端点响应不签名（Glitchtip 无需验证签名）。从 OIDC 集成介绍 的算法表可知，Authelia 对none之外的取值会要求对应的 JWK 配置，而none表示纯 JSON 输出。
• token_endpoint_auth_method: 'client_secret_basic'：客户端在令牌端点通过HTTP Basic 认证方式提交 Client ID 与 Secret 完成身份验证，这是机密型客户端的典型做法。

在 Glitchtip 中配置 OpenID Connect（Web GUI）

Glitchtip 侧只有一种配置方式：通过 Web GUI完成。具体操作如下：

1. 访问https://glitchtip.{{< sitevar name="domain" nojs="example.com" >}}/admin/socialaccount/socialapp/（Django Admin 的 Social Applications 管理页）。
2. 点击Add Social Application（添加社交应用）。
3. 按下表配置各项：

4. 点击页面底部的Save保存。

关于 Settings 中的 server_url

server_url指向 Authelia 的OpenID Connect Discovery 端点（即/.well-known/openid-configuration），Glitchtip 会通过该端点自动发现 Authelia 的授权端点、令牌端点、UserInfo 端点、JWKS 等元数据，从而无需手动填写这些 URL。根据 OIDC 集成介绍 中的端点清单，Authelia 的发现端点路径为/.well-known/openid-configuration，其返回的authorization_endpoint、token_endpoint、userinfo_endpoint等发现属性会指导 Glitchtip 完成整个授权码流程。

登录流程：一次完整的授权码交换

配置完成后，用户访问 Glitchtip 并选择以 Authelia 登录时，将发生如下流程（基于授权码流程的标准实现）：

1. Glitchtip 将用户重定向到 Authelia 的授权端点/api/oidc/authorization，携带client_id=glitchtip、response_type=code、redirect_uri=.../accounts/authelia/login/callback/、scope=openid email profile等参数。
2. Authelia 校验客户端配置后，要求用户完成登录与两步验证（由authorization_policy: 'two_factor'决定），并可能展示授权（Consent）确认页。
3. 认证通过后，Authelia 将授权码经回调地址返回给 Glitchtip。
4. Glitchtip 在令牌端点/api/oidc/token通过client_secret_basic方式验证自身身份，并交换得到 ID Token 与 Access Token。
5. Glitchtip 进一步调用 UserInfo 端点/api/oidc/userinfo获取email、profile等声明，用于匹配或创建本地账号，完成单点登录。

整个过程无需在 Glitchtip 侧重复输入密码，用户凭据完全由 Authelia 统一管理。

生产环境安全建议：生成安全的 Client ID 与 Client Secret

本指南示例中的glitchtip与insecure_secret仅用于演示。根据 Frequently Asked Questions 的官方建议，生产环境应遵循：

• 每个客户端使用唯一且随机生成的标识符与密钥对；
• 标识符与密钥长度大于 40 字符（官方推荐 72 字符）；
• 只使用 RFC3986 Unreserved Characters，避免某些实现未正确 URL 编码导致令牌端点认证失败；
• 密钥在 Authelia 配置中以哈希形式存储，而 Glitchtip 侧仍使用明文密钥。

Authelia 提供了便捷命令完成上述操作（裸金属环境，Docker 环境请在命令前加docker run --rm authelia/authelia:latest）：

# 生成 72 字符的随机 Client ID（RFC3986 安全字符集） authelia crypto rand --length 72 --charset rfc3986 # 生成 72 字符随机明文密钥，并输出其 PBKDF2-SHA512 哈希用于 Authelia 配置 authelia crypto hash generate pbkdf2 --variant sha512 --random --random.length 72 --random.charset rfc3986

第二条命令会同时输出随机明文与对应哈希：明文交给 Glitchtip 的 Secret Key，哈希填入 Authelia 的client_secret。更详细的生成指南见 Generating Secure Values。

延伸阅读

• OpenID Connect 1.0 集成介绍（端点、算法、支持矩阵）
• OpenID Connect 1.0 客户端配置完整参考
• OpenID Connect 1.0 Provider 配置指南
• OpenID Connect 常见问题（密钥生成、哈希、PKCE 等）
• Glitchtip 官方安装文档中的 OpenID Connect 配置章节（需提前创建 Django Admin 超级用户）

【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/authelia