Authelia 集成 Grafana使用 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本指南完整演示如何将 Grafana 作为 OpenID Connect 1.0 Relying Party依赖方接入 Authelia实现以 Authelia 为单一身份源的 SSO单点登录登录流程。你将掌握 Authelia 侧的 OIDC 客户端注册配置含 PKCE、Claims 策略等安全选项、Grafana 侧三种配置方式配置文件、环境变量、Docker Compose以及如何利用role_attribute_path将 Authelia 用户组自动映射为 Grafana 的 Admin / Editor / Viewer 角色。兼容性与测试前提该集成方案基于以下版本组合进行了验证详见 Grafana 集成文档组件版本Autheliav4.39.24Grafanav13.1.0本文示例基于以下假设请根据实际环境替换应用根地址Grafana Root URLhttps://grafana.example.com/Authelia 根地址即 OIDC Issuerhttps://auth.example.com/Client IDgrafanaClient Secretinsecure_secret仅用于演示生产环境必须自行生成见下文“客户端密钥安全”一节已知缺陷提示Claims Hydration根据仓库中 oidc-common shortcode 的定义当前版本的 Grafana 存在Claims Hydration缺陷——它不会按照 OpenID Connect 1.0 规范要求的过程使用 Access Token 从 UserInfo 端点拉取所需的 claims例如email、groups。官方文档明确评价该客户端“完全没有正确支持 OpenID Connect 1.0”并提供了对应的**配置逃生舱Configuration Escape Hatch**方案本文会完整给出。这也从侧面说明将sub与iss等稳定 claim 绑定本地账号、通过 UserInfo 端点获取常规 claims 才是规范做法。第一步在 Authelia 中注册 OIDC 客户端基础客户端配置Authelia 以 OpenID Connect 1.0 Provider 身份为 Grafana 提供认证。首先在 Authelia 的configuration.yml中注册客户端。以下是文档给出的示例配置identity_providers: oidc: ## OpenID Connect 1.0 Provider 的其余必填配置也在此处此处省略。 ## 完整参考docs/content/configuration/identity-providers/openid-connect/provider.md clients: - client_id: grafana client_name: Grafana 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://grafana.example.com/login/generic_oauth scopes: - openid - profile - groups - 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对上述关键选项逐一说明client_id/client_nameclient_id必须与 Grafana 侧配置完全一致且满足 客户端配置文档 中的约束全仓库唯一、不超过 100 字符、仅含 RFC3986 Unreserved Characters即字母、数字以及-、.、_、~。client_name是展示在 Authelia 界面上的友好名称缺省时与client_id相同。client_secret示例值insecure_secret的 PBKDF2 摘要严禁在生产环境直接使用。关于如何生成安全的客户端密钥见下文专门小节。public: false将 Grafana 声明为机密客户端confidential client配合token_endpoint_auth_method: client_secret_basic使用 HTTP Basic Auth 在 Token 端点完成客户端认证。在 OpenID Connect 1.0 介绍文档 的客户端认证方法表中client_secret_basic是机密客户端默认且推荐的认证方式。authorization_policy: two_factor访问该客户端需要用户完成双因素认证。Authelia 的授权策略还支持one_factor、bypass等取值。require_pkce: truepkce_challenge_method: S256强制启用 [RFC7636] 的 Proof Key for Code Exchange。Grafana 侧同时配置了use_pkce true两端必须一致。S256 方法由 Relying Party 生成随机的code_verifier经 SHA-256 摘要后 Base64URL 编码为code_challenge随授权请求发送换取令牌时再提交原始code_verifier从而防止授权码拦截攻击。redirect_urisGrafana 的 OAuth 回调地址必须精确匹配 Grafana 侧root_url与内置回调路径/login/generic_oauth的组合。scopesopenid启用 OIDC 语义、profile提供name、preferred_username等、groups提供用户组、email提供邮箱。response_types: [code]使用标准的 Authorization Code Flow这也是文档中grant_types仅配置authorization_code的原因。access_token_signed_response_alg: none/userinfo_signed_response_alg: noneAccess Token 与 UserInfo 响应不签名。Grafana 的 Generic OAuth 集成通过 UserInfo 端点换取用户信息none即返回纯 JSONapplication/json; charsetutf-8符合该客户端的处理能力。配置逃生舱Claims Policy如前所述Grafana 存在Claims Hydration缺陷它不会携带 Access Token 去 UserInfo 端点获取 claims。Authelia 为此提供了逃生舱机制——通过 claims_policies 把指定 claims 直接注入 ID Token从而恢复被破坏客户端的功能。文档oidc-escape-hatch-claims-hydration shortcode给出的适配配置如下identity_providers: oidc: claims_policies: grafana: id_token: [email, name, groups, preferred_username] clients: - client_id: grafana claims_policy: grafana其原理与背景详见 OpenID Connect 1.0 Claims 指南 的 “Restore Functionality Prior to Claims Parameter” 一节按规范通过 scope 授予的 claimsemail、name、groups、preferred_username等应通过 UserInfo 端点获取ID Token 默认只包含iss、sub、aud、exp、iat等证明授权发生的最小集合。对于不实现 UserInfo 请求、也不支持claims参数的客户端管理员可通过claims_policy将所需 claims 放入 ID Token 作为 break-glass 方案。注意该方案应仅注入目标客户端真正需要的 claims本例为 Grafana 登录所依赖的 4 个不宜照搬全部。客户端密钥安全示例中的client_secret是insecure_secret的 PBKDF2 摘要$pbkdf2-sha512$310000$...。根据 OIDC FAQAuthelia 强烈推荐以哈希形式存储客户端密钥明文存储已被正式弃用明文以$plaintext$前缀标识或不以$开头。可使用 Authelia CLI 同时生成随机密钥与其哈希# Docker 方式 docker run --rm authelia/authelia:latest authelia crypto hash generate pbkdf2 --variant sha512 --random --random.length 72 --random.charset rfc3986 # 裸机方式 authelia crypto hash generate pbkdf2 --variant sha512 --random --random.length 72 --random.charset rfc3986该命令生成 72 字符、仅含 RFC3986 无保留字符的随机密钥避免客户端 URL 编码问题并直接输出可用于配置文件的 PBKDF2 哈希。将明文密钥填入 Grafana 侧、将哈希填入 Authelia 配置即可。若客户端请求 Token 时出现超时可参考 FAQ 中 “Tuning the work factors” 一节调整 PBKDF2 迭代次数如--iterations 310000。第二步配置 Grafana 接入 AutheliaGrafana 通过内置的Generic OAuth认证模块对接 Authelia。文档提供了三种等效配置方式配置文件grafana.ini、环境变量、Docker Compose 环境变量。方式一配置文件grafana.iniGrafana 的配置文件通常命名为grafana.ini[server] root_url https://grafana.example.com [auth.generic_oauth] enabled true name Authelia icon signin client_id grafana client_secret insecure_secret scopes openid profile email groups empty_scopes false auth_url https://auth.example.com/api/oidc/authorization token_url https://auth.example.com/api/oidc/token api_url https://auth.example.com/api/oidc/userinfo login_attribute_path preferred_username groups_attribute_path groups name_attribute_path name use_pkce true role_attribute_path auth_style InHeader各选项的作用与对应关系[server] root_url必须与 Authelia 侧注册的redirect_uris前缀一致否则回调会被判定不匹配。auth_url/token_url/api_url分别对应 Authelia 的 Authorization、Token、UserInfo 三个端点。这些路径可在 OpenID Connect 1.0 介绍文档 的“端点实现”一节中确认/api/oidc/authorization、/api/oidc/token、/api/oidc/userinfo。login_attribute_path preferred_username将 UserInfo 中的preferred_usernameclaim 作为 Grafana 登录用户名由 Authelia 的profilescope 提供。groups_attribute_path groups将 Authelia 用户组groupsclaim导入 Grafana用于后续角色映射。name_attribute_path name将nameclaim 作为显示名。use_pkce true与 Authelia 侧require_pkce: true配对启用 S256 PKCE。auth_style InHeader客户端凭据以 HTTP HeaderBasic Auth方式发送到 Token 端点对应 Authelia 的client_secret_basic。role_attribute_path留空表示不做自动角色映射见下一节。方式二环境变量.envGrafana 支持将上述配置项一一映射为GF_前缀的环境变量配置键大写、点号与连字符转为下划线GF_SERVER_ROOT_URLhttps://grafana.example.com GF_AUTH_GENERIC_OAUTH_ENABLEDtrue GF_AUTH_GENERIC_OAUTH_NAMEAuthelia GF_AUTH_GENERIC_OAUTH_ICONsignin GF_AUTH_GENERIC_OAUTH_CLIENT_IDgrafana GF_AUTH_GENERIC_OAUTH_CLIENT_SECRETinsecure_secret GF_AUTH_GENERIC_OAUTH_SCOPESopenid profile email groups GF_AUTH_GENERIC_OAUTH_EMPTY_SCOPESfalse GF_AUTH_GENERIC_OAUTH_AUTH_URLhttps://auth.example.com/api/oidc/authorization GF_AUTH_GENERIC_OAUTH_TOKEN_URLhttps://auth.example.com/api/oidc/token GF_AUTH_GENERIC_OAUTH_API_URLhttps://auth.example.com/api/oidc/userinfo GF_AUTH_GENERIC_OAUTH_LOGIN_ATTRIBUTE_PATHpreferred_username GF_AUTH_GENERIC_OAUTH_GROUPS_ATTRIBUTE_PATHgroups GF_AUTH_GENERIC_OAUTH_NAME_ATTRIBUTE_PATHname GF_AUTH_GENERIC_OAUTH_USE_PKCEtrue GF_AUTH_GENERIC_OAUTH_ROLE_ATTRIBUTE_PATH GF_AUTH_GENERIC_OAUTH_AUTH_STYLEInHeader方式三Docker Compose若 Grafana 运行在 Docker Compose 中可将上述变量直接写入服务定义services: grafana: environment: GF_SERVER_ROOT_URL: https://grafana.example.com GF_AUTH_GENERIC_OAUTH_ENABLED: true GF_AUTH_GENERIC_OAUTH_NAME: Authelia GF_AUTH_GENERIC_OAUTH_ICON: signin GF_AUTH_GENERIC_OAUTH_CLIENT_ID: grafana GF_AUTH_GENERIC_OAUTH_CLIENT_SECRET: insecure_secret GF_AUTH_GENERIC_OAUTH_SCOPES: openid profile email groups GF_AUTH_GENERIC_OAUTH_EMPTY_SCOPES: false GF_AUTH_GENERIC_OAUTH_AUTH_URL: https://auth.example.com/api/oidc/authorization GF_AUTH_GENERIC_OAUTH_TOKEN_URL: https://auth.example.com/api/oidc/token GF_AUTH_GENERIC_OAUTH_API_URL: https://auth.example.com/api/oidc/userinfo GF_AUTH_GENERIC_OAUTH_LOGIN_ATTRIBUTE_PATH: preferred_username GF_AUTH_GENERIC_OAUTH_GROUPS_ATTRIBUTE_PATH: groups GF_AUTH_GENERIC_OAUTH_NAME_ATTRIBUTE_PATH: name GF_AUTH_GENERIC_OAUTH_USE_PKCE: true GF_AUTH_GENERIC_OAUTH_ROLE_ATTRIBUTE_PATH: GF_AUTH_GENERIC_OAUTH_AUTH_STYLE: InHeader第三步基于 Authelia 用户组自动映射 Grafana 角色role_attribute_path是可选配置用于将 Authelia 用户组自动映射为 Grafana 角色。如果不希望自动映射直接省略该配置项或对应的GF_AUTH_GENERIC_OAUTH_ROLE_ATTRIBUTE_PATH环境变量即可。该选项的值是 Grafana 的表达式语言基于 JMESPath 风格文档给出如下典型映射需求属于 Autheliaadmin组的用户 → GrafanaAdmin角色属于 Autheliaeditor组的用户 → GrafanaEditor角色其余用户 → GrafanaViewer角色。对应的role_attribute_path表达式为contains(groups[], admin) Admin || contains(groups[], editor) Editor || Viewer表达式中groups[]即 UserInfo 中groupsclaim 的数组依赖前文groups_attribute_path groups的取值contains判断数组是否包含指定组名/||构成短路求值的条件链最终返回角色字符串。更多取值方式可参考 Grafana 官方 “Configure role mapping” 文档。登录流程与验证要点完成上述配置后整体认证链路如下用户访问https://grafana.example.com点击 “Sign in with Authelia” 按钮Grafana 将浏览器重定向到https://auth.example.com/api/oidc/authorization携带response_typecode、client_idgrafana、PKCEcode_challenge等参数用户在 Authelia 完成认证按authorization_policy要求可能包含 2FAAuthelia 将授权码回传到 Grafana 的/login/generic_oauth回调Grafana 通过client_secret_basic认证方式携带code_verifier到/api/oidc/token换取 Access Token 与 ID TokenGrafana 使用 Access Token 请求/api/oidc/userinfo获取preferred_username、groups、name等 claims受 Claims Hydration 缺陷影响实际依赖逃生舱注入 ID Token 的 claims依据role_attribute_path完成角色映射并建立登录会话。验证时可重点关注回调地址是否与redirect_uris精确匹配、Grafana 侧auth_url/token_url/api_url三个端点是否可达、PKCE 与client_secret两端是否一致。若登录后角色不符合预期优先检查 UserInfo 是否返回了groupsclaim可通过 Authelia 的/api/oidc/userinfo端点配合 Access Token 自测以及role_attribute_path表达式中的组名拼写。小结本文基于 Grafana 集成文档完整覆盖了 Authelia 作为 OpenID Connect 1.0 Provider 对接 Grafana 的全部配置Authelia 客户端注册含 PKCE、机密客户端认证、Claims 逃生舱、Grafana 的配置文件 / 环境变量 / Docker Compose 三种接入方式以及基于用户组的角色自动映射。关键配置可进一步参考仓库中的 OpenID Connect 1.0 Clients 配置文档、Claims 指南 与 OIDC FAQ。【免费下载链接】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），仅供参考 
长河君 · 2026/9/11 16:53:07 · 阅读 1.2k Authelia 集成 Grafana：使用 OpenID Connect 1.0 实现统一身份认证与角色映射实战指南
Authelia 集成 Grafana使用 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本指南完整演示如何将 Grafana 作为 OpenID Connect 1.0 Relying Party依赖方接入 Authelia实现以 Authelia 为单一身份源的 SSO单点登录登录流程。你将掌握 Authelia 侧的 OIDC 客户端注册配置含 PKCE、Claims 策略等安全选项、Grafana 侧三种配置方式配置文件、环境变量、Docker Compose以及如何利用role_attribute_path将 Authelia 用户组自动映射为 Grafana 的 Admin / Editor / Viewer 角色。兼容性与测试前提该集成方案基于以下版本组合进行了验证详见 Grafana 集成文档组件版本Autheliav4.39.24Grafanav13.1.0本文示例基于以下假设请根据实际环境替换应用根地址Grafana Root URLhttps://grafana.example.com/Authelia 根地址即 OIDC Issuerhttps://auth.example.com/Client IDgrafanaClient Secretinsecure_secret仅用于演示生产环境必须自行生成见下文“客户端密钥安全”一节已知缺陷提示Claims Hydration根据仓库中 oidc-common shortcode 的定义当前版本的 Grafana 存在Claims Hydration缺陷——它不会按照 OpenID Connect 1.0 规范要求的过程使用 Access Token 从 UserInfo 端点拉取所需的 claims例如email、groups。官方文档明确评价该客户端“完全没有正确支持 OpenID Connect 1.0”并提供了对应的**配置逃生舱Configuration Escape Hatch**方案本文会完整给出。这也从侧面说明将sub与iss等稳定 claim 绑定本地账号、通过 UserInfo 端点获取常规 claims 才是规范做法。第一步在 Authelia 中注册 OIDC 客户端基础客户端配置Authelia 以 OpenID Connect 1.0 Provider 身份为 Grafana 提供认证。首先在 Authelia 的configuration.yml中注册客户端。以下是文档给出的示例配置identity_providers: oidc: ## OpenID Connect 1.0 Provider 的其余必填配置也在此处此处省略。 ## 完整参考docs/content/configuration/identity-providers/openid-connect/provider.md clients: - client_id: grafana client_name: Grafana 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://grafana.example.com/login/generic_oauth scopes: - openid - profile - groups - 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对上述关键选项逐一说明client_id/client_nameclient_id必须与 Grafana 侧配置完全一致且满足 客户端配置文档 中的约束全仓库唯一、不超过 100 字符、仅含 RFC3986 Unreserved Characters即字母、数字以及-、.、_、~。client_name是展示在 Authelia 界面上的友好名称缺省时与client_id相同。client_secret示例值insecure_secret的 PBKDF2 摘要严禁在生产环境直接使用。关于如何生成安全的客户端密钥见下文专门小节。public: false将 Grafana 声明为机密客户端confidential client配合token_endpoint_auth_method: client_secret_basic使用 HTTP Basic Auth 在 Token 端点完成客户端认证。在 OpenID Connect 1.0 介绍文档 的客户端认证方法表中client_secret_basic是机密客户端默认且推荐的认证方式。authorization_policy: two_factor访问该客户端需要用户完成双因素认证。Authelia 的授权策略还支持one_factor、bypass等取值。require_pkce: truepkce_challenge_method: S256强制启用 [RFC7636] 的 Proof Key for Code Exchange。Grafana 侧同时配置了use_pkce true两端必须一致。S256 方法由 Relying Party 生成随机的code_verifier经 SHA-256 摘要后 Base64URL 编码为code_challenge随授权请求发送换取令牌时再提交原始code_verifier从而防止授权码拦截攻击。redirect_urisGrafana 的 OAuth 回调地址必须精确匹配 Grafana 侧root_url与内置回调路径/login/generic_oauth的组合。scopesopenid启用 OIDC 语义、profile提供name、preferred_username等、groups提供用户组、email提供邮箱。response_types: [code]使用标准的 Authorization Code Flow这也是文档中grant_types仅配置authorization_code的原因。access_token_signed_response_alg: none/userinfo_signed_response_alg: noneAccess Token 与 UserInfo 响应不签名。Grafana 的 Generic OAuth 集成通过 UserInfo 端点换取用户信息none即返回纯 JSONapplication/json; charsetutf-8符合该客户端的处理能力。配置逃生舱Claims Policy如前所述Grafana 存在Claims Hydration缺陷它不会携带 Access Token 去 UserInfo 端点获取 claims。Authelia 为此提供了逃生舱机制——通过 claims_policies 把指定 claims 直接注入 ID Token从而恢复被破坏客户端的功能。文档oidc-escape-hatch-claims-hydration shortcode给出的适配配置如下identity_providers: oidc: claims_policies: grafana: id_token: [email, name, groups, preferred_username] clients: - client_id: grafana claims_policy: grafana其原理与背景详见 OpenID Connect 1.0 Claims 指南 的 “Restore Functionality Prior to Claims Parameter” 一节按规范通过 scope 授予的 claimsemail、name、groups、preferred_username等应通过 UserInfo 端点获取ID Token 默认只包含iss、sub、aud、exp、iat等证明授权发生的最小集合。对于不实现 UserInfo 请求、也不支持claims参数的客户端管理员可通过claims_policy将所需 claims 放入 ID Token 作为 break-glass 方案。注意该方案应仅注入目标客户端真正需要的 claims本例为 Grafana 登录所依赖的 4 个不宜照搬全部。客户端密钥安全示例中的client_secret是insecure_secret的 PBKDF2 摘要$pbkdf2-sha512$310000$...。根据 OIDC FAQAuthelia 强烈推荐以哈希形式存储客户端密钥明文存储已被正式弃用明文以$plaintext$前缀标识或不以$开头。可使用 Authelia CLI 同时生成随机密钥与其哈希# Docker 方式 docker run --rm authelia/authelia:latest authelia crypto hash generate pbkdf2 --variant sha512 --random --random.length 72 --random.charset rfc3986 # 裸机方式 authelia crypto hash generate pbkdf2 --variant sha512 --random --random.length 72 --random.charset rfc3986该命令生成 72 字符、仅含 RFC3986 无保留字符的随机密钥避免客户端 URL 编码问题并直接输出可用于配置文件的 PBKDF2 哈希。将明文密钥填入 Grafana 侧、将哈希填入 Authelia 配置即可。若客户端请求 Token 时出现超时可参考 FAQ 中 “Tuning the work factors” 一节调整 PBKDF2 迭代次数如--iterations 310000。第二步配置 Grafana 接入 AutheliaGrafana 通过内置的Generic OAuth认证模块对接 Authelia。文档提供了三种等效配置方式配置文件grafana.ini、环境变量、Docker Compose 环境变量。方式一配置文件grafana.iniGrafana 的配置文件通常命名为grafana.ini[server] root_url https://grafana.example.com [auth.generic_oauth] enabled true name Authelia icon signin client_id grafana client_secret insecure_secret scopes openid profile email groups empty_scopes false auth_url https://auth.example.com/api/oidc/authorization token_url https://auth.example.com/api/oidc/token api_url https://auth.example.com/api/oidc/userinfo login_attribute_path preferred_username groups_attribute_path groups name_attribute_path name use_pkce true role_attribute_path auth_style InHeader各选项的作用与对应关系[server] root_url必须与 Authelia 侧注册的redirect_uris前缀一致否则回调会被判定不匹配。auth_url/token_url/api_url分别对应 Authelia 的 Authorization、Token、UserInfo 三个端点。这些路径可在 OpenID Connect 1.0 介绍文档 的“端点实现”一节中确认/api/oidc/authorization、/api/oidc/token、/api/oidc/userinfo。login_attribute_path preferred_username将 UserInfo 中的preferred_usernameclaim 作为 Grafana 登录用户名由 Authelia 的profilescope 提供。groups_attribute_path groups将 Authelia 用户组groupsclaim导入 Grafana用于后续角色映射。name_attribute_path name将nameclaim 作为显示名。use_pkce true与 Authelia 侧require_pkce: true配对启用 S256 PKCE。auth_style InHeader客户端凭据以 HTTP HeaderBasic Auth方式发送到 Token 端点对应 Authelia 的client_secret_basic。role_attribute_path留空表示不做自动角色映射见下一节。方式二环境变量.envGrafana 支持将上述配置项一一映射为GF_前缀的环境变量配置键大写、点号与连字符转为下划线GF_SERVER_ROOT_URLhttps://grafana.example.com GF_AUTH_GENERIC_OAUTH_ENABLEDtrue GF_AUTH_GENERIC_OAUTH_NAMEAuthelia GF_AUTH_GENERIC_OAUTH_ICONsignin GF_AUTH_GENERIC_OAUTH_CLIENT_IDgrafana GF_AUTH_GENERIC_OAUTH_CLIENT_SECRETinsecure_secret GF_AUTH_GENERIC_OAUTH_SCOPESopenid profile email groups GF_AUTH_GENERIC_OAUTH_EMPTY_SCOPESfalse GF_AUTH_GENERIC_OAUTH_AUTH_URLhttps://auth.example.com/api/oidc/authorization GF_AUTH_GENERIC_OAUTH_TOKEN_URLhttps://auth.example.com/api/oidc/token GF_AUTH_GENERIC_OAUTH_API_URLhttps://auth.example.com/api/oidc/userinfo GF_AUTH_GENERIC_OAUTH_LOGIN_ATTRIBUTE_PATHpreferred_username GF_AUTH_GENERIC_OAUTH_GROUPS_ATTRIBUTE_PATHgroups GF_AUTH_GENERIC_OAUTH_NAME_ATTRIBUTE_PATHname GF_AUTH_GENERIC_OAUTH_USE_PKCEtrue GF_AUTH_GENERIC_OAUTH_ROLE_ATTRIBUTE_PATH GF_AUTH_GENERIC_OAUTH_AUTH_STYLEInHeader方式三Docker Compose若 Grafana 运行在 Docker Compose 中可将上述变量直接写入服务定义services: grafana: environment: GF_SERVER_ROOT_URL: https://grafana.example.com GF_AUTH_GENERIC_OAUTH_ENABLED: true GF_AUTH_GENERIC_OAUTH_NAME: Authelia GF_AUTH_GENERIC_OAUTH_ICON: signin GF_AUTH_GENERIC_OAUTH_CLIENT_ID: grafana GF_AUTH_GENERIC_OAUTH_CLIENT_SECRET: insecure_secret GF_AUTH_GENERIC_OAUTH_SCOPES: openid profile email groups GF_AUTH_GENERIC_OAUTH_EMPTY_SCOPES: false GF_AUTH_GENERIC_OAUTH_AUTH_URL: https://auth.example.com/api/oidc/authorization GF_AUTH_GENERIC_OAUTH_TOKEN_URL: https://auth.example.com/api/oidc/token GF_AUTH_GENERIC_OAUTH_API_URL: https://auth.example.com/api/oidc/userinfo GF_AUTH_GENERIC_OAUTH_LOGIN_ATTRIBUTE_PATH: preferred_username GF_AUTH_GENERIC_OAUTH_GROUPS_ATTRIBUTE_PATH: groups GF_AUTH_GENERIC_OAUTH_NAME_ATTRIBUTE_PATH: name GF_AUTH_GENERIC_OAUTH_USE_PKCE: true GF_AUTH_GENERIC_OAUTH_ROLE_ATTRIBUTE_PATH: GF_AUTH_GENERIC_OAUTH_AUTH_STYLE: InHeader第三步基于 Authelia 用户组自动映射 Grafana 角色role_attribute_path是可选配置用于将 Authelia 用户组自动映射为 Grafana 角色。如果不希望自动映射直接省略该配置项或对应的GF_AUTH_GENERIC_OAUTH_ROLE_ATTRIBUTE_PATH环境变量即可。该选项的值是 Grafana 的表达式语言基于 JMESPath 风格文档给出如下典型映射需求属于 Autheliaadmin组的用户 → GrafanaAdmin角色属于 Autheliaeditor组的用户 → GrafanaEditor角色其余用户 → GrafanaViewer角色。对应的role_attribute_path表达式为contains(groups[], admin) Admin || contains(groups[], editor) Editor || Viewer表达式中groups[]即 UserInfo 中groupsclaim 的数组依赖前文groups_attribute_path groups的取值contains判断数组是否包含指定组名/||构成短路求值的条件链最终返回角色字符串。更多取值方式可参考 Grafana 官方 “Configure role mapping” 文档。登录流程与验证要点完成上述配置后整体认证链路如下用户访问https://grafana.example.com点击 “Sign in with Authelia” 按钮Grafana 将浏览器重定向到https://auth.example.com/api/oidc/authorization携带response_typecode、client_idgrafana、PKCEcode_challenge等参数用户在 Authelia 完成认证按authorization_policy要求可能包含 2FAAuthelia 将授权码回传到 Grafana 的/login/generic_oauth回调Grafana 通过client_secret_basic认证方式携带code_verifier到/api/oidc/token换取 Access Token 与 ID TokenGrafana 使用 Access Token 请求/api/oidc/userinfo获取preferred_username、groups、name等 claims受 Claims Hydration 缺陷影响实际依赖逃生舱注入 ID Token 的 claims依据role_attribute_path完成角色映射并建立登录会话。验证时可重点关注回调地址是否与redirect_uris精确匹配、Grafana 侧auth_url/token_url/api_url三个端点是否可达、PKCE 与client_secret两端是否一致。若登录后角色不符合预期优先检查 UserInfo 是否返回了groupsclaim可通过 Authelia 的/api/oidc/userinfo端点配合 Access Token 自测以及role_attribute_path表达式中的组名拼写。小结本文基于 Grafana 集成文档完整覆盖了 Authelia 作为 OpenID Connect 1.0 Provider 对接 Grafana 的全部配置Authelia 客户端注册含 PKCE、机密客户端认证、Claims 逃生舱、Grafana 的配置文件 / 环境变量 / Docker Compose 三种接入方式以及基于用户组的角色自动映射。关键配置可进一步参考仓库中的 OpenID Connect 1.0 Clients 配置文档、Claims 指南 与 OIDC FAQ。【免费下载链接】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），仅供参考