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），僅供參考 Authelia 與 RustDesk Server Pro 集成指南：通過 OpenID Connect 1.0 實現單點登錄
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），僅供參考