使用 Authelia OpenID Connect 1.0 为 Chronograf 配置单点登录：完整实战指南

使用 Authelia OpenID Connect 1.0 为 Chronograf 配置单点登录：完整实战指南

【免费下载链接】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 官方集成文档，指导你如何将时序数据库监控面板 Chronograf 接入 Authelia 的 OpenID Connect 1.0 提供方（OP），实现统一身份认证与单点登录。读完本文，你将掌握 Authelia 侧 OIDC 客户端注册的完整 YAML 配置、Chronograf 侧全部环境变量的含义与取值、两种部署形态（.env 与 Docker Compose）的落地写法，以及该方案背后由源码支撑的 PKCE、授权策略、令牌端点认证等关键机制，可直接复制到你的生产或测试环境中运行。

集成概述与适用场景

Chronograf 是 InfluxData 提供的时序数据可视化与监控面板。在自建监控体系（如 InfluxDB + Chronograf）中，往往不希望再为 Chronograf 维护一套独立的用户体系，而是希望与已有的身份提供方（如 Authelia）统一登录入口。

Authelia 内置 OpenID Connect 1.0 提供方能力，可作为 OpenID Connect 1.0 的 Relying Party（即客户端应用）的身份认证后端。本指南对应的官方文档位于 docs/content/integration/openid-connect/clients/chronograf/index.md，属于社区（community）支持级别的集成，官方已用 Authelia v4.39.24 与 Chronograf v1.10.7 完成过实际测试验证。

从源码结构看，Authelia 的 OIDC 提供方实现了 Authorization Code Flow 等标准流程，并完整支持 PKCE、客户端密钥认证（client_secret_basic）等机制，这为 Chronograf 这类仅实现了"通用 OAuth 2.0 Provider"接入模式的应用提供了稳定的对接基础。

开始之前：通用前置说明

按照官方集成模板（见 docs/layouts/_shortcodes/oidc-common.html），在动手配置任何 OpenID Connect 1.0 注册客户端之前，有几个通用要点必须清楚：

1. client_id必须全站唯一：每个客户端都必须使用不同的值；本文使用的chronograf仅为可读性而设，生产环境不应直接使用，建议参考 FAQ 生成 64 位随机字符，且只能包含 RFC3986 Unreserved Characters，长度不得超过 100 字符。
2. client_secret建议以哈希形式存储：明文存储虽仍可用但已被弃用，未来版本不保证继续支持。当密钥以哈希形式存储时，过高的哈希工作因子可能引发客户端超时，需要合理调优工作因子。
3. 示例只展示客户端注册片段：你必须同时按 OpenID Connect 1.0 Provider 配置指南 完成提供方的其余必填配置（如签发者、密钥等），并建议通读 OpenID Connect 1.0 Clients 配置指南 了解全部可选项及其影响。

本文示例的前提假设

本指南示例基于以下假设，你可以按自己的域名替换：

注意：insecure_secret仅为演示值，生产环境绝对不要使用。

Authelia 侧配置：注册 OIDC 客户端

在 Authelia 的configuration.yml中，为 Chronograf 注册一个 OIDC 客户端，配置如下：

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: 'chronograf' client_name: 'Chronograf' client_secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'. public: false authorization_policy: 'two_factor' require_pkce: true pkce_challenge_method: 'S256' redirect_uris: - 'https://chronograf.example.com/oauth/authelia/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'

关键配置项逐一解读

结合 internal/configuration/schema/identity_providers.go 中的客户端结构定义与默认值（见DefaultOpenIDConnectClientConfiguration，位于同文件 L272-L286），对各配置项说明如下：

• client_id：客户端唯一标识，Chronograf 侧将以此值作为GENERIC_CLIENT_ID。
• client_name：展示给终端用户的应用名。
• client_secret：客户端密钥。示例中给出的是insecure_secret的 PBKDF2-SHA512 摘要（$pbkdf2-sha512$...），即推荐的安全存储形态。密钥类型在结构体中定义为*PasswordDigest，意味着既支持摘要也兼容（但已弃用的）明文。
• public: false：标记为机密（confidential）客户端，允许使用client_secret_basic这类基于密钥的认证方式；public类型默认使用none认证方式。
• authorization_policy: 'two_factor'：授权策略，默认值即为two_factor（双因素）。这意味着用户登录 Chronograf 时需要完成两步认证；若希望仅密码即可，可改为one_factor。
• require_pkce: true+pkce_challenge_method: 'S256'：强制要求 Proof Key for Code Exchange（PKCE，见 RFC 7636），并将质询方法固定为S256。这是针对授权码拦截攻击的关键加固手段。schema 中pkce_challenge_method的合法取值为空、plain、S256。
• redirect_uris：回调地址白名单，必须与 Chronograf 配置的oauth/authelia/callback完全一致，任何不匹配的跳转都会被拒绝。
• scopes：允许请求并被授予的权限范围。schema 支持的合法 scope 包括openid、offline_access、profile、email、address、phone、groups、authelia.bearer.authz、authelia.pam（见同文件 L179）。本例仅需openid、email、profile。
• response_types: ['code']：仅启用 Authorization Code Flow。schema 中合法值包括code、id_token、token、code token、code id_token、code id_token token等。
• grant_types: ['authorization_code']：仅允许授权码授权类型；如需刷新令牌需额外加入refresh_token。
• access_token_signed_response_alg: 'none'/userinfo_signed_response_alg: 'none'：访问令牌与 UserInfo 响应不签名。这两个字段的默认值即none（参见默认配置 L280-L281），Chronograf 通过GENERIC_API_URL拉取 UserInfo 时解析的是纯 JSON 响应。
• token_endpoint_auth_method: 'client_secret_basic'：令牌端点认证方式，即通过 HTTP Basic Auth 携带客户端凭证。schema 中该字段默认值即为client_secret_basic，合法值还包括none、client_secret_post、private_key_jwt、client_secret_jwt。

关于端点路径：Authelia 的 OIDC 端点路径与本文 Chronograf 环境变量中的 URL 一一对应，例如授权端点为/api/oidc/authorization、令牌端点为/api/oidc/token、UserInfo 端点为/api/oidc/userinfo、JWKS 端点为/jwks.json。这些路径在 OpenID Connect 集成导论 中有完整列表，并被 internal/handlers 下的处理器测试（如handler_oauth2_authorization_test.go）反复印证。

Chronograf 侧配置：环境变量接入

Chronograf 接入 Authelia 只有一种方式：通过环境变量（Environment Variables）。官方文档将其概括为"使用任意 OAuth 2.0 Provider"的通用配置模式。

标准环境变量（.env）

PUBLIC_URL=https://chronograf.example.com TOKEN_SECRET=insecure_random_secret GENERIC_CLIENT_ID=chronograf GENERIC_CLIENT_SECRET=insecure_secret GENERIC_AUTH_URL=https://auth.example.com/api/oidc/authorization GENERIC_TOKEN_URL=https://auth.example.com/api/oidc/token JWKS_URL=https://auth.example.com/jwks.json GENERIC_API_URL=https://auth.example.com/api/oidc/userinfo GENERIC_API_KEY=email GENERIC_SCOPES=openid,email,profile GENERIC_NAME=authelia

各变量的作用如下：

Docker Compose 部署形态

若 Chronograf 以容器方式运行，可在compose.yml的environment段直接注入上述变量：

services: chronograf: environment: PUBLIC_URL: 'https://chronograf.example.com' TOKEN_SECRET: 'insecure_random_secret' GENERIC_CLIENT_ID: 'chronograf' GENERIC_CLIENT_SECRET: 'insecure_secret' GENERIC_AUTH_URL: 'https://auth.example.com/api/oidc/authorization' GENERIC_TOKEN_URL: 'https://auth.example.com/api/oidc/token' JWKS_URL: 'https://auth.example.com/jwks.json' GENERIC_API_URL: 'https://auth.example.com/api/oidc/userinfo' GENERIC_API_KEY: 'email' GENERIC_SCOPES: 'openid,email,profile' GENERIC_NAME: 'authelia'

两种形态的取值完全一致，区别仅在于变量承载方式（文件 vs 编排文件），你可以根据实际部署方式任选其一。

登录流程与底层机制

完成两端配置后，用户访问 Chronograf 的登录流程大致如下：

1. 用户点击 Chronograf 登录页中的 "authelia"（即GENERIC_NAME）入口，Chronograf 将用户重定向到GENERIC_AUTH_URL（Authelia 授权端点）。
2. Authelia 根据authorization_policy: 'two_factor'要求用户完成密码 + 第二因素的认证（如 TOTP、WebAuthn 等）。
3. 认证通过后，Authelia 将授权码通过redirect_uris中登记的回调地址送回 Chronograf。
4. Chronograf 携带授权码与客户端凭证，向GENERIC_TOKEN_URL请求令牌。由于启用了require_pkce: true，该请求还必须携带与授权请求绑定的code_verifier。
5. Chronograf 取得令牌后，调用GENERIC_API_URL（UserInfo 端点）获取用户声明，并以GENERIC_API_KEY指定的email字段识别并建立本地会话。

其中第 4 步的 PKCE 绑定关系是安全关键：S256 方法要求 Relying Party 在授权请求中发送code_challenge（即对code_verifier做 SHA-256 摘要后的 Base64URL 编码），在令牌请求中再发送原始code_verifier，从而证明赎回授权码的一方确实持有最初生成它的实体（详见 集成导论中的 PKCE 说明）。即便客户端属于无法在令牌端点认证的公开类型，这一机制也能有效缓解授权码拦截攻击。

验证与故障排查要点

配置完成后，建议按以下顺序自检：

1. 核对回调地址：Authelia 侧redirect_uris与 Chronograf 侧PUBLIC_URL + /oauth/authelia/callback必须完全一致（含协议与端口），否则授权请求会被拒绝。
2. 核对 scope 一致性：GENERIC_SCOPES不能超出 Authelia 侧scopes白名单，否则令牌端点会因 scope 越权而报错。
3. 确认客户端类型：public: false与token_endpoint_auth_method: 'client_secret_basic'是配套的，若误将客户端设为public，则不能使用client_secret_basic。
4. 关注密钥哈希开销：若client_secret使用高成本哈希存储，需留意令牌端点的响应延迟，必要时按 FAQ 中的工作因子调优指引 降低成本参数。
5. 查阅官方参考：Chronograf 侧更多关于安全与 OAuth 2.0 的说明，可参考 InfluxData 官方文档中 "Configure Chronograf to use any OAuth 2.0 provider" 一节；Authelia 侧的完整客户端选项请以 OpenID Connect 1.0 Clients 配置文档 为准。

延伸阅读

• Authelia OpenID Connect 1.0 集成导论：了解支持的全部端点、算法、授权类型与安全机制。
• OpenID Connect 1.0 Clients 配置文档：客户端全部可配置项与默认值。
• OpenID Connect 1.0 Provider 配置文档：提供方层面的必填配置（签发者、密钥等）。
• OpenID Connect 1.0 常见问题：涵盖客户端标识/密钥生成、哈希工作因子调优等实操问题。
• 客户端配置 Schema 源码：查看客户端结构体字段定义、合法枚举值与默认配置（DefaultOpenIDConnectClientConfiguration）。

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