Authelia 与 RustDesk Server Pro 集成指南通过 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本篇技术指南讲解如何将 Authelia 作为 OpenID Connect 1.0OIDCProvider与 RustDesk Server Pro 这一自托管远程桌面服务进行集成使用户可以使用 Authelia 的统一身份认证体系登录 RustDesk Server Pro。读完本文你将掌握在 Authelia 中注册 OIDC 客户端所需的完整 YAML 配置与每个关键参数的含义、在 RustDesk Server Pro Web 管理界面中创建 OIDC Auth Provider 的逐步操作、以及各 OIDC 端点授权、令牌、UserInfo、JWKS在 Authelia 中的真实路径与对应源码依据。测试版本与集成前提该集成指南基于以下版本组合验证通过Autheliav4.39.24RustDesk Server Prov1.3.9本文示例遵循以下假设你在实际部署时应替换为真实域名项目假设值应用根地址RustDesk Server Prohttps://rustdesk.example.com/Authelia 根地址OIDC Issuerhttps://auth.example.com/Client IDrustdeskClient Secretinsecure_secret仅演示用生产环境严禁使用重要提示配置一个 OpenID Connect 1.0 注册客户端之前请务必先阅读 Authelia 官方的 OpenID Connect 1.0 集成总览 以及 OpenID Connect 1.0 客户端配置指南了解 Provider 与客户端的基础概念与全部可用选项。前置必读客户端标识与密钥规范在开始配置之前有几条关于client_id与client_secret的硬性规则需要牢记详见 常见问题 与 客户端配置client_id对每个客户端必须唯一长度不超过 100 字符且只能包含 RFC3986 Unreserved Characters字母、数字及-、.、_、~。client_secret是 Authelia 与应用之间的共享密钥必须与 RustDesk Server Pro 侧配置的密钥完全一致。本文与示例中的rustdesk/insecure_secret仅用于演示生产环境绝对不要使用应使用随机生成的高强度值。强烈建议以哈希形式将client_secret存入 Authelia 配置而非明文明文存储已被正式弃用详见下文“密钥存储与工作因子”小节。Authelia 提供了便捷的命令生成符合上述规范的值避免 URL 编码问题生成 72 字符的随机 Client ID# Docker 方式 docker run --rm authelia/authelia:latest authelia crypto rand --length 72 --charset rfc3986 # 裸机方式 authelia crypto rand --length 72 --charset rfc3986生成随机 Client Secret 并同时输出其 PBKDF2 哈希明文用于 RustDesk 侧哈希用于 Authelia 配置# 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如果生成的字符集在 URL 编码后会产生不同的值Authelia 会额外打印一份预编码版本方便你处理不支持正确编码的应用。第一步在 Authelia 中注册 OIDC 客户端以下 YAML 是适用于 RustDesk Server Pro 的 Authelia 客户端配置 示例可直接放入configuration.yml的identity_providers.oidc.clients列表identity_providers: oidc: ## 此处省略 OpenID Connect 1.0 Provider 的其他必填配置。 ## 请参见 Provider 配置指南补齐 issuer、jwks 等全局项。 clients: - client_id: rustdesk client_name: RustDesk Server Pro client_secret: $pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng # insecure_secret 的哈希 public: false authorization_policy: two_factor require_pkce: false pkce_challenge_method: redirect_uris: - https://rustdesk.example.com/api/oidc/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关键参数逐项解析配置项取值说明client_idrustdesk客户端唯一标识必须与 RustDesk Server Pro 中填写的 Client ID 完全一致。client_nameRustDesk Server Pro在 Authelia 界面中展示的友好名称缺省时与client_id相同。client_secret$pbkdf2-sha512$...共享密钥的 PBKDF2 哈希对应明文insecure_secret。此配置项在客户端为机密型confidential时必填若使用非 Secret 凭证的认证方法或公开型客户端public: true则需留空。publicfalse声明为机密型客户端。RustDesk Server Pro 是服务端程序可安全持有凭证故为false。authorization_policytwo_factor该客户端授权时要求的认证强度可选one_factor、two_factor或 Provider 中通过 authorization_policies 自定义的策略名。注意它只作用于 Authorization Request与访问控制规则是两套独立机制。require_pkcefalse是否强制要求该客户端使用 PKCE。RustDesk Server Pro 的 OIDC 实现不发送 PKCE 参数故此处关闭开启后若客户端不支持会导致授权失败。pkce_challenge_method空强制指定的 PKCE challenge 方法合法值为空、plain或S256推荐。设置后等价于开启require_pkce。redirect_urishttps://rustdesk.example.com/api/oidc/callback允许回调的 URI 白名单大小写敏感必须精确匹配 RustDesk 发起授权后回跳的地址其他回调一律视为不安全并被拒绝。scopesopenid、email、profile允许该客户端申请的 scope缺省值为openid,groups,profile,email。应结合 scope 定义 与应用实际需要配置。response_typescode授权码流程。安全上建议只用code其他响应类型implicit/hybrid安全性较弱。grant_typesauthorization_code允许的授权类型。授权码是 OAuth 2.0 / OIDC 最通用的流程缺省即为authorization_code。access_token_signed_response_algnoneAccess Token 的签名算法。Authelia 默认颁发不透明Access Token即noneRustDesk Server Pro 通过 UserInfo 端点换取用户信息故无需签名。userinfo_signed_response_algnoneUserInfo 端点响应的签名算法none表示以普通 JSON 返回application/json。token_endpoint_auth_methodclient_secret_basic客户端在 Token 端点认证的方式即以 HTTP Basic 方式携带 Client ID 与 Secret。Authelia 支持的取值包括client_secret_basic、client_secret_post、client_secret_jwt、private_key_jwt、none等详见 集成总览的客户端认证方法表。注意以上示例只展示了客户端注册的部分选项。实际部署时你还必须补齐 OpenID Connect 1.0 Provider 配置 中的全局必填项如issuer、jwks密钥配置等。client_secret中的$pbkdf2-sha512$310000$...前缀表明其迭代次数为 310000若你的硬件性能较弱且客户端频繁超时可参考下文“工作因子调优”。第二步在 RustDesk Server Pro 中创建 OIDC Auth ProviderRustDesk Server Pro 提供了唯一一种集成方式——通过其Web 管理界面完成配置。按以下步骤操作登录 RustDesk Server Pro。进入Settings设置。进入OIDC页面。点击 New Auth Provider新建认证提供方。按下表配置各项配置项值NameAutheliaClient IDrustdeskClient Secretinsecure_secret此处填写明文与 Authelia 配置中哈希对应的原文一致Issuerhttps://auth.example.comAuthorization Endpointhttps://auth.example.com/api/oidc/authorizationToken Endpointhttps://auth.example.com/api/oidc/tokenUserinfo Endpointhttps://auth.example.com/api/oidc/userinfoJWKS Endpointhttps://auth.example.com/jwks.json点击页面底部的Submit提交保存配置。配置完成后用户在 RustDesk 客户端选择 OIDC 登录时将被重定向到 Authelia 门户完成认证按authorization_policy要求可能包含两步验证认证通过后回跳至https://rustdesk.example.com/api/oidc/callback完成会话建立。端点路径的源码依据上表中的端点并非随意填写而是 Authelia 实际实现的固定路径。在 OpenID Connect 1.0 集成总览 的端点表中这些路径以 Authelia 根 URL 为前缀授权端点/api/oidc/authorization对应authorization_endpoint令牌端点/api/oidc/token对应token_endpointUserInfo 端点/api/oidc/userinfo对应userinfo_endpoint撤销端点/api/oidc/revocation内省端点/api/oidc/introspectionJWKS/jwks.json对应jwks_uri发现端点/.well-known/openid-configuration与/.well-known/oauth-authorization-server这些路径同样可以从仓库源码与测试中得到印证例如 handler_oauth2_authorization_test.go 中定义了testOIDCAuthorizationEndpoint https://login.example.com:8080/api/oidc/authorizationhandler_oauth2_consent_test.go 等测试也以/api/oidc/...为请求 URI。如果你的 RustDesk 版本支持 OpenID Connect Discovery 1.0更推荐直接通过https://auth.example.com/.well-known/openid-configuration自动发现全部端点避免手工填写的笔误手工填写时请确保以上地址与 Authelia 实际部署的根 URL 一致。密钥存储、工作因子与安全加固为什么client_secret建议存哈希Authelia技术层面仍支持在配置中存放明文client_secret不带$前缀或使用$plaintext$前缀但这一行为已被正式弃用未来版本很可能彻底移除。按 RFC6819 Section 5.1.4.1.3 的要求授权服务器应当只以哈希/摘要形式存储客户端密钥Authelia 当前并未实现任何必须在明文下读取密钥的规范如client_secret_jwt因此明文存放没有任何必要。正确做法是RustDesk 侧填明文Authelia 配置中填该明文的 PBKDF2 哈希即本文示例的形态。工作因子调优Authelia 在每次客户端认证时会执行 PBKDF2 哈希运算计算耗时随迭代次数310000和硬件性能变化。如果 RustDesk Server Pro 与 Authelia 交互时出现超时可以降低工作因子。先测量不同迭代次数的耗时time authelia crypto hash generate pbkdf2 --variant sha512 --iterations 310000 --password insecure_password测量时不必使用真实密钥耗时与密码长度基本无关然后选择合适的迭代次数重新生成client_secret哈希并更新配置。其他建议require_pkce、require_pushed_authorization_requests等加固选项需要客户端支持RustDesk Server Pro 的 OIDC 实现不发送 PKCE 参数因此本示例保持关闭不要盲目开启导致登录失败。若你的部署暴露在公网请为 Authelia 配置强密码策略与双因素认证authorization_policy: two_factor已覆盖 OIDC 登录流程。关于 PKCE、Pushed Authorization Requests、JARM 等安全机制的完整讨论可参阅 OpenID Connect 1.0 集成总览的安全章节。验证与排错思路配置完成后可通过以下方式验证集成是否生效打开 RustDesk 客户端选择使用 OIDC 登录确认浏览器跳转到https://auth.example.com的 Authelia 登录页。登录成功后确认浏览器回跳至https://rustdesk.example.com/api/oidc/callback且 RustDesk Server Pro 会话建立成功。若登录失败优先检查client_secret是否与 Authelia 配置中哈希对应的明文完全一致redirect_uris是否与 RustDesk 实际回调地址精确匹配大小写敏感各端点 URL 前缀是否为 Authelia 真实根地址Authelia 日志中是否有与 scope、grant_type 或客户端认证相关的错误提示。延伸阅读RustDesk Server Pro OIDC 官方文档Authelia OpenID Connect 1.0 集成总览OpenID Connect 1.0 客户端配置指南OpenID Connect 1.0 Provider 配置指南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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考