Authelia 与 Cloud Identity Engine 集成指南：通过 OpenID Connect 1.0 对接 Palo Alto 云身份引擎实现企业 SSO-开发者社区

Authelia 与 Cloud Identity Engine 集成指南：通过 OpenID Connect 1.0 对接 Palo Alto 云身份引擎实现企业 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 内置的 OpenID Connect 1.0 Provider 为核心，完整演示如何将 Palo Alto Networks 的 Cloud Identity Engine（云身份引擎）注册为 Authelia 的 OIDC 客户端，使企业用户能够通过 Authelia 的登录门户（含双因子认证）完成 Cloud Identity Engine 的认证。读完本文，你将掌握 Authelia 侧 OIDC 客户端的完整 YAML 配置方法与每个关键参数的含义，以及 Cloud Identity Engine 管理后台中 OIDC 认证类型的 8 步图形化配置流程，并理解授权码流程、PKCE 与 token 端点认证等底层机制。

测试版本

本文档所述集成方案在以下版本组合上验证通过：

组件	版本
Authelia	v4.39.24
Cloud Identity Engine	未固定具体版本（以官方当前发布版本为准）

需要说明的是，Authelia 的 OpenID Connect 1.0 Provider 目前仍处于开放测试（open beta）阶段，但 Authelia 已通过 OpenID Certified 认证，涵盖 Basic OP / Implicit OP / Hybrid OP / Form Post OP / Config OP 等 profile。集成前建议阅读 OpenID Connect 1.0 集成介绍了解 Provider 的能力边界（端点、算法、授权类型支持矩阵等）。

开始前的必读事项

在动手配置前，有几个与client_id和client_secret相关的硬性约束必须先了解，这些约束来自 OpenID Connect 1.0 客户端配置文档与集成 FAQ，直接决定配置是否能通过校验：

关于client_id（Client ID）：

该值对每个客户端必须唯一，不能与其它已注册客户端重复。
本文使用的cloudidentityengine仅为便于阅读和演示，生产环境不应直接使用，而应参照如何生成 Client ID 与 Client Secret 中的建议生成（推荐 64 个随机字符，且长度不低于 40 字符）。
只能包含 RFC3986 定义的 Unreserved Characters（即字母、数字以及-、.、_、~）。
长度不得超过 100 个字符。

关于client_secret（Client Secret）：

本文使用的insecure_secret同样仅用于演示，绝对不要在生产环境使用该值。
该字符串可以直接以明文形式写在 Authelia 配置中，但此行为已被标记为弃用，未来不保证继续支持；强烈推荐以哈希形式存储。Authelia 的client_secret支持多种哈希格式（如$pbkdf2-sha512$...、bcrypt、scrypt 等），从 internal/commands/crypto_hash.go 可以看到authelia crypto hash generate命令支持pbkdf2、sha2-crypt、bcrypt、scrypt、argon2等子命令用于生成这些哈希。需要注意：哈希只用于 Authelia 配置中的client_secret字段，Cloud Identity Engine 侧填入的仍是明文密钥。
哈希计算成本（迭代次数等）如果设置过高，可能导致客户端认证超时，相关调优方法见 Tuning the work factors 常见问题。

关于配置示例本身：

下文给出的 Authelia 配置示例只包含客户端注册部分，你必须同时按 OpenID Connect 1.0 Provider 配置指南补齐 Provider 层级的必填配置（如issuer、密钥、以及access_token_lifespan等生命周期选项）。
该示例只展示了客户端可用配置选项的一小部分，authorization_policy、consent_mode、claims_policy、lifespan、各端点响应算法的签名/加密 key 等大量选项都未涉及，建议通读 OpenID Connect 1.0 Clients 配置文档了解全部选项及其影响。

前提假设

本示例基于以下假设值展开，你可以根据自身环境替换：

Authelia Root URL：https://auth.example.com/
Client ID：cloudidentityengine
Client Secret：insecure_secret

其中部分值在官方文档中可通过文档变量自动替换（如将auth.example.com中的子域与域名替换为你实际的站点变量），下文统一以默认值auth.example.com为例书写。

第一步：配置 Authelia 的 OIDC 客户端

在 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: 'cloudidentityengine' client_name: 'Cloud Identity Engine' 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: - '' # Replace with the value copied in step 7. 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_post'

注意：redirect_uris中的空字符串是占位符，需要在下文 Cloud Identity Engine 配置完成后，将第 7 步复制到的Callback URL / Redirect URL回填到这里。

关键配置参数详解

以下逐一拆解上述配置中每个参数的作用与取值依据（来源：OpenID Connect 1.0 Clients 配置文档）：

client_id（必填）：客户端标识符，必须与 Cloud Identity Engine 中填写的 Client ID 完全一致。约束如上文所述（唯一、≤100 字符、仅含 RFC3986 非保留字符）。
client_name（可选）：显示在 Authelia 用户界面上的友好名称，默认与client_id相同。
client_secret（confidential 客户端必填）：Authelia 与 Cloud Identity Engine 之间的共享密钥。示例中给出的是明文insecure_secret的 PBKDF2-SHA512 摘要（310000 次迭代），这是推荐的存储形式。
public（布尔，默认false）：置为false表示本客户端属于机密客户端（confidential client type），能够安全保管凭证；机密类型要求必须配置client_secret。若置为true则要求client_secret为空字符串，适用于 SPA、CLI 等无法保密凭证的场景（参见 RFC6749 Section 2.1）。
authorization_policy（字符串，默认two_factor）：该客户端在 Authorization Request 中采用的授权策略，可选one_factor、two_factor，或 Provider 级authorization_policies中自定义的策略名。该策略仅作用于 OIDC 授权请求本身，与 Authelia 的访问控制规则（Access Control Rules）是两套独立机制，不应混用。
require_pkce（布尔，默认false）：强制该客户端使用 PKCE（Proof Key for Code Exchange）。也可以在 Provider 层级用enforce_pkce对全部客户端全局开启。
pkce_challenge_method（字符串，默认空）：强制指定 PKCE 挑战方法，合法值为空字符串、plain、S256。配置了非空值后等效于同时开启require_pkce。只要依赖方支持，强烈推荐S256——它将code_verifier经 SHA-256 摘要后 Base64URL 编码得到code_challenge，有效抵御授权码拦截攻击。
redirect_uris（必填）：该客户端允许回调的 URI 白名单，大小写敏感，scheme 必须是http或https，不在列表中的回调会被拒绝。此处的空值占位需要回填 Cloud Identity Engine 生成的回调地址。
scopes（列表，默认openid,groups,profile,email）：允许该客户端请求的 scope 集合，应与 Cloud Identity Engine 实际需要的 claims 匹配。scope 定义可参考 OpenID Connect 1.0 Claims 文档。
response_types（列表，默认code）：允许的响应类型。安全上只推荐使用code（即纯授权码流程），其它隐式/混合流程安全性较差。
grant_types（列表，默认authorization_code）：允许客户端获取令牌的授权类型。本示例仅开放authorization_code，不配置刷新令牌（refresh_token）与client_credentials等类型。
access_token_signed_response_alg（默认none）：置为none时 Access Token 以不透明（opaque）字符串形式签发；若配置为其它算法，则按 RFC9068 将 Access Token 编码为 JWT，供资源服务器做无状态校验，但不应把 JWT Profile Access Token 当作身份证明来使用。
userinfo_signed_response_alg（默认none）：置为none时 UserInfo 端点返回普通 JSON；配置非none值后，整个 UserInfo 响应会变为签名 JWT。绝大多数客户端只支持none。
token_endpoint_auth_method（默认client_secret_basic）：客户端在 Token 端点的认证方式。本示例使用client_secret_post（密钥经 HTTP POST body 提交）。规格要求 confidential 客户端默认client_secret_basic，public 客户端默认none。

底层流程支撑

从 OpenID Connect 1.0 集成介绍可以确认与本次集成相关的 Authelia 端点实现（均挂在 Authelia Root URL 之下）：

OpenID Connect Discovery：/.well-known/openid-configuration
OAuth 2.0 Authorization Server Metadata：/.well-known/oauth-authorization-server
JSON Web Key Set：/jwks.json
Authorization Endpoint：/api/oidc/authorization
Token Endpoint：/api/oidc/token
UserInfo Endpoint：/api/oidc/userinfo
Introspection：/api/oidc/introspection
Revocation：/api/oidc/revocation
Pushed Authorization Request：/api/oidc/pushed-authorization-request

本次集成走的是标准的Authorization Code Flow + PKCE：Cloud Identity Engine 将用户引导至https://auth.example.com/api/oidc/authorization，Authelia 完成身份认证（此处为two_factor，即密码 + 第二因素）与授权码签发；随后 Cloud Identity Engine 在 Token 端点使用client_secret_post认证并携带code_verifier兑换令牌；用户信息通过 UserInfo 端点（/api/oidc/userinfo）获取openid、email、profilescope 对应的 claims。

第二步：配置 Cloud Identity Engine

Cloud Identity Engine 侧只有一种配置方式，即通过其 Web 管理界面（Web GUI）完成，具体步骤如下：

登录你的 Cloud Identity Engine 管理员账户。
选择Authentication（认证）。
选择Authentication Types（认证类型）。
选择Add New Authentication Type（添加新认证类型）。
在OIDC下选择Set Up（设置）。
填写以下值：
- Authentication Type Name（认证类型名称）：Authelia
- Client Name（客户端名称）：Authelia
- Client ID（客户端 ID）：cloudidentityengine
- Client Secret（客户端密钥）：insecure_secret
- OIDC Issuer URL（OIDC 签发者 URL）：https://auth.example.com
- JWT Encryption Algorithm（JWT 加密算法）：RS256
- OIDC Authentication Server Discovery Endpoint（OIDC 认证服务器发现端点，可选）：https://auth.example.com/.well-known/openid-configuration
点击Callback URL / Redirect URL旁边的复制按钮，将复制到的回调地址回填到 Authelia 配置中该客户端的redirect_uris里。
点击Submit（提交）。

完成以上步骤后，Cloud Identity Engine 即完成对 Authelia 这个 OIDC Provider 的注册，企业用户即可通过 Authelia 门户完成认证与授权。

安全加固建议

密钥生成：生产环境务必按 FAQ 的生成建议为每个客户端生成唯一、随机、长度超过 40 字符的 ID 与密钥对；client_secret在 Authelia 配置中应以支持哈希的格式存储（可用authelia crypto hash generate pbkdf2等命令生成，见 internal/commands/crypto_hash.go），而 Cloud Identity Engine 中填写的是明文密钥。
严格限定回调：redirect_uris只登记 Cloud Identity Engine 实际生成的那一个回调地址，避免开放任意回调导致授权码被劫持。
开启 PKCE：本示例已通过require_pkce: true与pkce_challenge_method: 'S256'强制 PKCE，这是抵御授权码拦截攻击的关键措施。
最小化 scope：scopes仅授予openid、email、profile，不额外开放groups、offline_access等非必要范围。
保持none算法：在 Cloud Identity Engine 明确支持签名响应之前，access_token_signed_response_alg与userinfo_signed_response_alg保持none即可；若未来需要 JWT 格式的 Access Token，可参考 RFC9068 的语义调整，但切勿将 JWT Access Token 用作身份凭证。