使用 Authelia OpenID Connect 1.0 集成 Cloudflare Zero Trust 实现企业级 SSO 登录【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/autheliaAuthelia 作为一款开源的多因素认证MFA与单点登录SSO门户其内置的 OpenID Connect 1.0 Provider 允许任何符合 OIDC 标准的应用接入统一身份认证。本文以 Cloudflare Zero Trust 的通用 OIDC 集成为例给出 Authelia 侧完整的客户端注册配置、Cloudflare 侧 Web 控制台配置步骤并针对该集成中已知的 Claims Hydration 缺陷给出官方提供的配置逃生通道Escape Hatch方案。阅读完本文后你将能够独立完成 Authelia 与 Cloudflare Zero Trust 的对接理解 OIDC 客户端配置中各关键参数的语义并掌握应对不兼容第三方客户端的标准处理思路。集成概述与前置假设该集成属于社区支持级别support level: community对应文档位于 docs/content/integration/openid-connect/clients/cloudflare-zerotrust/index.md集成方式为在 Cloudflare Zero Trust 中添加 Authelia 作为 OIDC 身份提供方进而让 Cloudflare Access 保护的资源统一走 Authelia 登录认证。官方示例基于以下假设值生产环境必须替换假设项示例值说明Cloudflare Team Nameexample-teamCloudflare Zero Trust 的团队子域前缀Authelia Root URLhttps://auth.example.com/Authelia 部署的根地址即 OIDC IssuerClient IDcloudflare注册到 Authelia 的客户端标识Client Secretinsecure_secret客户端共享密钥示例值仅用于演示示例中的subdomain-autheliaauth与domainexample.com可以使用官方文档变量自动替换接入你自己的实际域名。重要前置条件Cloudflare 的服务器必须能够请求到 Authelia 的 URL。这通常意味着这些 URL 需要对公网可访问foreign clients on the internet 可达。Cloudflare 侧或许存在无需公网可达的配置方式但超出了本文档范围实施前请务必确认网络可达性否则回调无法完成。在 Authelia 中注册 OIDC 客户端在 Authelia 的configuration.yml中通过identity_providers.oidc.clients列表注册 Cloudflare Zero Trust 客户端完整示例配置如下摘自原文档并保留全部字段identity_providers: oidc: ## The other portions of the mandatory OpenID Connect 1.0 configuration go here. clients: - client_id: cloudflare client_name: Cloudflare ZeroTrust 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://example-team.cloudflareaccess.com/cdn-cgi/access/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关键参数逐项解析client_id / client_name客户端唯一标识与 UI 展示名称。client_id必须与 Cloudflare 侧配置的 App ID 完全一致且需满足 ≤100 字符、仅含 RFC3986 Unreserved 字符、与其他客户端唯一这三个约束见 docs/content/configuration/identity-providers/openid-connect/clients.md。client_secret与 Cloudflare 共享的密钥。官方强烈建议使用 PBKDF2-SHA512 摘要形式而非明文存储示例中即为insecure_secret的哈希值。注意当密钥以哈希形式存储时过高的哈希成本可能导致客户端超时可参考 FAQ 中的Tuning the work factors进行调优若使用明文存储该行为已标记为 deprecated未来可能不再支持。生产环境请通过authelia crypto hash generate等命令生成自己的摘要切勿沿用示例值。public: false声明为机密型confidential客户端可在 Token Endpoint 使用密钥进行认证。authorization_policy: two_factor对该客户端的授权请求强制要求双因素认证。它仅作用于 OIDC 授权请求与访问控制规则Access Control Rules是两套独立机制不要混淆。require_pkce pkce_challenge_method: S256强制要求 PKCERFC 7636并指定S256挑战方法。启用后客户端必须在授权请求中携带code_challenge并在令牌请求中证明对code_verifier的持有可缓解授权码拦截攻击。源码中对应常量见 internal/oidc/const.goPKCEChallengeMethodSHA256 S256。redirect_uris授权回调地址白名单本例为 Cloudflare Access 的固定回调路径https://example-team.cloudflareaccess.com/cdn-cgi/access/callback大小写敏感未列入的 URI 一律拒绝见 clients.md#redirect_uris。scopes允许该客户端请求的 scope。profile与email对应的身份属性只在 UserInfo Endpoint 按规范返回不会直接塞进 ID Token详见后文 Claims 说明。response_types: [code]仅允许最安全的授权码流程Authorization Code Flow。clients 文档明确建议只使用code类型其余类型安全性较差。grant_types: [authorization_code]限制客户端可用的授权类型防止误用密码模式等其他不安全的 grant。access_token_signed_response_alg / userinfo_signed_response_alg: noneAccess Token 与 UserInfo 响应不做 JWT 签名以普通 JSON 返回。默认值即none见 clients.md此处显式写出以便对照。若改为其他算法Access Token 将按 RFC 9068 编码为 JWT其验证语义与 ID Token 不同仅建议在无状态校验的高负载场景启用。token_endpoint_auth_method: client_secret_basic客户端在 Token Endpoint 使用 HTTP Basic 认证携带密钥这是机密型客户端的规范默认值对应常量见 internal/oidc/const.go。除上述字段外完整客户端配置还支持sector_identifier_uri、consent_mode、lifespan、claims_policy、各端点的 JARM/加密算法、jwks等大量可选参数完整字段清单见 OpenID Connect 1.0 Clients 配置指南。已知缺陷与配置逃生通道Escape Hatch官方在集成文档中通过oidc-commonshortcode见 docs/layouts/_shortcodes/oidc-common.html标注了该客户端存在的两项已知显著缺陷Known BugsClient Credentials EncodingCloudflare 未按 RFC 6749 Appendix B 的要求在client_secret_basic/client_secret_post认证前对 Client ID 与 Client Secret 做 URL 转义。唯一规避方式是避免在 Client ID 与 Client Secret 中使用特殊字符Authelia 的随机密码生成器会同时输出普通版与预编码版。Claims HydrationCloudflare 没有按 OIDC 规范通过 UserInfo Endpoint 获取 claims因此无法正确获得其所需的用户属性官方判定该客户端outright does not support OpenID Connect 1.0。针对 Claims Hydration官方提供了配置逃生通道。其原理详见 docs/content/integration/openid-connect/openid-connect-1.0-claims.mdOIDC 规范5.4 Requesting Claims using Scope Values规定 scope 申请的 claims 应通过 UserInfo Endpoint 获取ID Token 只保留规范必需的最小 claims。对于不访问 UserInfo 端点又不支持claims参数的非规范客户端Authelia 允许通过claims_policies为单个客户端恢复旧行为把属性直接注入 ID Token。为 Cloudflare 客户端补充如下配置identity_providers: oidc: claims_policies: cloudflare: id_token: [preferred_username, mail, email, groups, name, email_verified] clients: - client_id: cloudflare claims_policy: cloudflare该策略为id_token声明了注入的 claims 列表并将策略绑定到cloudflare客户端。官方建议尽量只注入实际必需的 claims 而非全部此机制定位为break-glass应急手段标准做法仍应是通过 Access Token 调用 UserInfo Endpoint 获取属性。同时官方也指出需要该通道往往意味着客户端还忽略了 claims 稳定性要求规范只允许以sub与iss锚定账号配置前应优先推动应用方修复。在 Cloudflare Zero Trust 中配置 Authelia 作为身份提供方Cloudflare 侧官方仅提供 Web GUI 一种配置方式步骤如下访问 Cloudflare Zero Trust Dashboarddash.cloudflare.com/one。进入Integrations。进入Identity providers。点击Add an identity provider。选择OpenID Connect。按下表配置配置项值NameAutheliaApp IDcloudflare与 Authelia 端 client_id 一致Client Secretinsecure_secret与 Authelia 端 client_secret 明文一致Auth URLhttps://auth.example.com/api/oidc/authorizationToken URLhttps://auth.example.com/api/oidc/tokenCertificate URLhttps://auth.example.com/jwks.jsonProof Key for Code Exchange (PKCE)启用EnableOIDC Claims添加preferred_username、mail点击 Save 保存。上述三个端点路径对应 Authelia OIDC Provider 的官方实现见 docs/content/integration/openid-connect/introduction.md 中的端点表与源码 internal/oidc/discovery_test.go 验证的https://example.com/api/oidc/authorization一致Authorization Endpoint/api/oidc/authorizationToken Endpoint/api/oidc/tokenJSON Web Key Set/jwks.jsonCloudflare 要求配置的 OIDC Claimspreferred_username与mail需要配合前述 claims 策略或通过 UserInfo才能正确填充这正是整个集成中Authelia 配置 Cloudflare 配置必须配套完成的原因。此外若在你的部署中二者不一致应以实际部署域名替换auth.example.com。常见问题与生产化建议客户端认证编码问题由于 Cloudflare 不会对凭据做 URL 编码务必保证 Client ID 与 Client Secret 不含特殊字符否则认证将失败。ID Token 与 claims 的关系即便配置了profile、emailscope规范行为也是通过 UserInfo 返回对应 claims若你的 Cloudflare 策略需要用户名/邮箱做条件判断而拿不到值优先排查是否已正确配置并绑定claims_policy。网络可达性确认 Cloudflare 边缘节点能访问你的 Authelia 公网地址否则授权回调与令牌交换都会中断。测试版本官方在该集成指南中标注的测试版本为 Authelia v4.39.24其他版本可能存在差异请以你实际部署版本的文档为准。总结通过本文的配置你将 Cloudflare Zero Trust 的 Access 策略认证委托给了 Authelia用户在访问受 Cloudflare Access 保护的资源时会被重定向到 Authelia 完成含双因素在内的认证认证通过后由 Cloudflare 侧基于 OIDC 返回的身份 claims 执行访问控制。整个方案的核心在于三处配套设置Authelia 端的客户端注册含redirect_uris、PKCE、scope/response/grant 类型、Cloudflare 端的 Identity Provider 配置含三个端点 URL 与 claims 映射以及针对 Claims Hydration 缺陷的 claims 策略逃生通道。若需要进一步了解 OIDC 客户端全部可用选项可继续阅读 OpenID Connect 1.0 Clients 配置指南关于 claims 机制的完整讨论见 OpenID Connect 1.0 Claims 指南。【免费下载链接】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），仅供参考
使用 Authelia OpenID Connect 1.0 集成 Cloudflare Zero Trust 实现企业级 SSO 登录
使用 Authelia OpenID Connect 1.0 集成 Cloudflare Zero Trust 实现企业级 SSO 登录【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/autheliaAuthelia 作为一款开源的多因素认证MFA与单点登录SSO门户其内置的 OpenID Connect 1.0 Provider 允许任何符合 OIDC 标准的应用接入统一身份认证。本文以 Cloudflare Zero Trust 的通用 OIDC 集成为例给出 Authelia 侧完整的客户端注册配置、Cloudflare 侧 Web 控制台配置步骤并针对该集成中已知的 Claims Hydration 缺陷给出官方提供的配置逃生通道Escape Hatch方案。阅读完本文后你将能够独立完成 Authelia 与 Cloudflare Zero Trust 的对接理解 OIDC 客户端配置中各关键参数的语义并掌握应对不兼容第三方客户端的标准处理思路。集成概述与前置假设该集成属于社区支持级别support level: community对应文档位于 docs/content/integration/openid-connect/clients/cloudflare-zerotrust/index.md集成方式为在 Cloudflare Zero Trust 中添加 Authelia 作为 OIDC 身份提供方进而让 Cloudflare Access 保护的资源统一走 Authelia 登录认证。官方示例基于以下假设值生产环境必须替换假设项示例值说明Cloudflare Team Nameexample-teamCloudflare Zero Trust 的团队子域前缀Authelia Root URLhttps://auth.example.com/Authelia 部署的根地址即 OIDC IssuerClient IDcloudflare注册到 Authelia 的客户端标识Client Secretinsecure_secret客户端共享密钥示例值仅用于演示示例中的subdomain-autheliaauth与domainexample.com可以使用官方文档变量自动替换接入你自己的实际域名。重要前置条件Cloudflare 的服务器必须能够请求到 Authelia 的 URL。这通常意味着这些 URL 需要对公网可访问foreign clients on the internet 可达。Cloudflare 侧或许存在无需公网可达的配置方式但超出了本文档范围实施前请务必确认网络可达性否则回调无法完成。在 Authelia 中注册 OIDC 客户端在 Authelia 的configuration.yml中通过identity_providers.oidc.clients列表注册 Cloudflare Zero Trust 客户端完整示例配置如下摘自原文档并保留全部字段identity_providers: oidc: ## The other portions of the mandatory OpenID Connect 1.0 configuration go here. clients: - client_id: cloudflare client_name: Cloudflare ZeroTrust 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://example-team.cloudflareaccess.com/cdn-cgi/access/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关键参数逐项解析client_id / client_name客户端唯一标识与 UI 展示名称。client_id必须与 Cloudflare 侧配置的 App ID 完全一致且需满足 ≤100 字符、仅含 RFC3986 Unreserved 字符、与其他客户端唯一这三个约束见 docs/content/configuration/identity-providers/openid-connect/clients.md。client_secret与 Cloudflare 共享的密钥。官方强烈建议使用 PBKDF2-SHA512 摘要形式而非明文存储示例中即为insecure_secret的哈希值。注意当密钥以哈希形式存储时过高的哈希成本可能导致客户端超时可参考 FAQ 中的Tuning the work factors进行调优若使用明文存储该行为已标记为 deprecated未来可能不再支持。生产环境请通过authelia crypto hash generate等命令生成自己的摘要切勿沿用示例值。public: false声明为机密型confidential客户端可在 Token Endpoint 使用密钥进行认证。authorization_policy: two_factor对该客户端的授权请求强制要求双因素认证。它仅作用于 OIDC 授权请求与访问控制规则Access Control Rules是两套独立机制不要混淆。require_pkce pkce_challenge_method: S256强制要求 PKCERFC 7636并指定S256挑战方法。启用后客户端必须在授权请求中携带code_challenge并在令牌请求中证明对code_verifier的持有可缓解授权码拦截攻击。源码中对应常量见 internal/oidc/const.goPKCEChallengeMethodSHA256 S256。redirect_uris授权回调地址白名单本例为 Cloudflare Access 的固定回调路径https://example-team.cloudflareaccess.com/cdn-cgi/access/callback大小写敏感未列入的 URI 一律拒绝见 clients.md#redirect_uris。scopes允许该客户端请求的 scope。profile与email对应的身份属性只在 UserInfo Endpoint 按规范返回不会直接塞进 ID Token详见后文 Claims 说明。response_types: [code]仅允许最安全的授权码流程Authorization Code Flow。clients 文档明确建议只使用code类型其余类型安全性较差。grant_types: [authorization_code]限制客户端可用的授权类型防止误用密码模式等其他不安全的 grant。access_token_signed_response_alg / userinfo_signed_response_alg: noneAccess Token 与 UserInfo 响应不做 JWT 签名以普通 JSON 返回。默认值即none见 clients.md此处显式写出以便对照。若改为其他算法Access Token 将按 RFC 9068 编码为 JWT其验证语义与 ID Token 不同仅建议在无状态校验的高负载场景启用。token_endpoint_auth_method: client_secret_basic客户端在 Token Endpoint 使用 HTTP Basic 认证携带密钥这是机密型客户端的规范默认值对应常量见 internal/oidc/const.go。除上述字段外完整客户端配置还支持sector_identifier_uri、consent_mode、lifespan、claims_policy、各端点的 JARM/加密算法、jwks等大量可选参数完整字段清单见 OpenID Connect 1.0 Clients 配置指南。已知缺陷与配置逃生通道Escape Hatch官方在集成文档中通过oidc-commonshortcode见 docs/layouts/_shortcodes/oidc-common.html标注了该客户端存在的两项已知显著缺陷Known BugsClient Credentials EncodingCloudflare 未按 RFC 6749 Appendix B 的要求在client_secret_basic/client_secret_post认证前对 Client ID 与 Client Secret 做 URL 转义。唯一规避方式是避免在 Client ID 与 Client Secret 中使用特殊字符Authelia 的随机密码生成器会同时输出普通版与预编码版。Claims HydrationCloudflare 没有按 OIDC 规范通过 UserInfo Endpoint 获取 claims因此无法正确获得其所需的用户属性官方判定该客户端outright does not support OpenID Connect 1.0。针对 Claims Hydration官方提供了配置逃生通道。其原理详见 docs/content/integration/openid-connect/openid-connect-1.0-claims.mdOIDC 规范5.4 Requesting Claims using Scope Values规定 scope 申请的 claims 应通过 UserInfo Endpoint 获取ID Token 只保留规范必需的最小 claims。对于不访问 UserInfo 端点又不支持claims参数的非规范客户端Authelia 允许通过claims_policies为单个客户端恢复旧行为把属性直接注入 ID Token。为 Cloudflare 客户端补充如下配置identity_providers: oidc: claims_policies: cloudflare: id_token: [preferred_username, mail, email, groups, name, email_verified] clients: - client_id: cloudflare claims_policy: cloudflare该策略为id_token声明了注入的 claims 列表并将策略绑定到cloudflare客户端。官方建议尽量只注入实际必需的 claims 而非全部此机制定位为break-glass应急手段标准做法仍应是通过 Access Token 调用 UserInfo Endpoint 获取属性。同时官方也指出需要该通道往往意味着客户端还忽略了 claims 稳定性要求规范只允许以sub与iss锚定账号配置前应优先推动应用方修复。在 Cloudflare Zero Trust 中配置 Authelia 作为身份提供方Cloudflare 侧官方仅提供 Web GUI 一种配置方式步骤如下访问 Cloudflare Zero Trust Dashboarddash.cloudflare.com/one。进入Integrations。进入Identity providers。点击Add an identity provider。选择OpenID Connect。按下表配置配置项值NameAutheliaApp IDcloudflare与 Authelia 端 client_id 一致Client Secretinsecure_secret与 Authelia 端 client_secret 明文一致Auth URLhttps://auth.example.com/api/oidc/authorizationToken URLhttps://auth.example.com/api/oidc/tokenCertificate URLhttps://auth.example.com/jwks.jsonProof Key for Code Exchange (PKCE)启用EnableOIDC Claims添加preferred_username、mail点击 Save 保存。上述三个端点路径对应 Authelia OIDC Provider 的官方实现见 docs/content/integration/openid-connect/introduction.md 中的端点表与源码 internal/oidc/discovery_test.go 验证的https://example.com/api/oidc/authorization一致Authorization Endpoint/api/oidc/authorizationToken Endpoint/api/oidc/tokenJSON Web Key Set/jwks.jsonCloudflare 要求配置的 OIDC Claimspreferred_username与mail需要配合前述 claims 策略或通过 UserInfo才能正确填充这正是整个集成中Authelia 配置 Cloudflare 配置必须配套完成的原因。此外若在你的部署中二者不一致应以实际部署域名替换auth.example.com。常见问题与生产化建议客户端认证编码问题由于 Cloudflare 不会对凭据做 URL 编码务必保证 Client ID 与 Client Secret 不含特殊字符否则认证将失败。ID Token 与 claims 的关系即便配置了profile、emailscope规范行为也是通过 UserInfo 返回对应 claims若你的 Cloudflare 策略需要用户名/邮箱做条件判断而拿不到值优先排查是否已正确配置并绑定claims_policy。网络可达性确认 Cloudflare 边缘节点能访问你的 Authelia 公网地址否则授权回调与令牌交换都会中断。测试版本官方在该集成指南中标注的测试版本为 Authelia v4.39.24其他版本可能存在差异请以你实际部署版本的文档为准。总结通过本文的配置你将 Cloudflare Zero Trust 的 Access 策略认证委托给了 Authelia用户在访问受 Cloudflare Access 保护的资源时会被重定向到 Authelia 完成含双因素在内的认证认证通过后由 Cloudflare 侧基于 OIDC 返回的身份 claims 执行访问控制。整个方案的核心在于三处配套设置Authelia 端的客户端注册含redirect_uris、PKCE、scope/response/grant 类型、Cloudflare 端的 Identity Provider 配置含三个端点 URL 与 claims 映射以及针对 Claims Hydration 缺陷的 claims 策略逃生通道。若需要进一步了解 OIDC 客户端全部可用选项可继续阅读 OpenID Connect 1.0 Clients 配置指南关于 claims 机制的完整讨论见 OpenID Connect 1.0 Claims 指南。【免费下载链接】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），仅供参考
