我正在為幾個不同的使用者設定工作流程。我如何為他們每個人設定認證，而不需要取得他們的個人帳戶，或者他們可以自己建立嗎？
如果你使用的 n8n 版本已啟用使用者管理功能（在 n8n Cloud 和大多數自架部署中可用），該流程非常簡單：
- 邀請使用者： 你透過電子郵件邀請使用者加入你的 n8n 執行個體。
- 私人認證： 使用者登入後，他們建立的任何認證預設情況下只有他們能使用。
- 工作流程執行： 當你為他們建立工作流程時，可以將認證欄位留空或設定為預留位置。使用者開啟工作流程時，只需從下拉式選單中選擇自己預先設定的認證。
對於支援 OAuth2 的服務（如 Google、Slack、Microsoft 等），使用者無需將密碼告訴你：
- 你在該服務的開發者控制台中設定「應用程式」（用戶端識別碼和用戶端密碼）。
- 使用者點擊 n8n 中的**「連線我的帳戶」**按鈕。
- 他們被重新導向到該服務自己的登入頁面（例如 Google 的登入畫面），在該頁面授權 n8n。
- n8n 收到「權杖」以代表他們行動，但你永遠看不到他們的實際登入認證。
如果你建立了「服務帳戶」（公司使用的通用帳戶），並希望多個使用者在不知道密碼的情況下使用它：
- 你在管理員帳戶下建立認證。
- 在認證設定中，你可以共用該特定認證給其他使用者或特定角色。
- 使用者隨後可在其工作流程中選擇該共用認證，但他們無法查看或編輯實際的 API 金鑰或密碼。
這取決於你設定的認證類型。
對於共享服務（Slack 機器人、資料庫連線、內部 API，或任何一個帳戶為整個團隊服務的情況）：你可以自己建立認證，然後開啟它並點擊分享標籤。有一個下拉選單可以與特定使用者或專案共享。他們可以在工作流程中使用它，但看不到實際的 API 金鑰或密鑰。這些資訊會保持鎖定狀態，只有你作為擁有者可以存取。
對於個人 OAuth 帳戶（每個人自己的 Gmail、Google 雲端硬碟、Notion 等）：沒有其他辦法。每個使用者都需要用自己的帳戶進行身份驗證。你無法在不以他們身份登入的情況下代替他們進行。好消息是程序對他們來說跟對你來說是一樣的：認證 → 新增認證 → 選擇服務 → 完成 OAuth 流程。只要他們在你的執行個體上有 n8n 帳戶，他們就可以自己完成。
所以實際上：你設定共享服務認證並分享給團隊，你的團隊成員為任何與他們個人帳戶相關的東西建立自己的認證。
有一個小細節值得了解：與你共享認證的使用者可以在工作流程中使用該認證，但無法檢視或編輯底層的密鑰。如果他們的權杖過期或出現其他問題，要麼你重新分享一個新的，要麼他們需要自己重新驗證。最好一開始就設定好這個預期。
嗨！我發現這個帖子是因為我自己關於Credential HUB的討論被列在相關主題下。
從閱讀你的使用案例來看，我認為你可能面臨Credential HUB為解決而構建的問題之一：集中式憑證管理、工作流程的受控存取、憑證生命週期與輪換、健康監測，以及用於自動化平台的一致API。
它可能適合也可能不適合你的設置，但如果你有興趣，這是該項目的概述以及它旨在解決的問題：
我會非常感謝來自面臨類似挑戰的人的任何反饋或想法。
Luis
是的，他們可以建立自己的帳戶——通常也應該這樣做。
關鍵點： 你永遠不需要他們的密碼。對於 OAuth 服務（Google、Slack、Microsoft），你設定一次應用程式設定，他們 點擊「連接」並授權自己的帳戶。
1. 邀請他們加入你的實例。 他們建立憑證並將其共享到專案中。你可以使用它，但無法檢視或編輯密鑰。適用於所有雲端方案。
共享 工作流程 會繞過此限制——編輯者可以存取其中的每個憑證。
2. 終端使用者憑證（企業版、預覽版）。一個憑證範本，每個使用者連接自己的帳戶。執行使用觸發它的使用者。
僅限 OAuth，且僅限手動/Chat Hub/MCP 觸發——不支援排程或 webhook。
3. 每個客戶端一個獨立實例。 他們擁有帳戶並邀請你加入。最清晰的界限，易於交接。缺點：在實例之間切換。
4. 服務帳戶（僅限 Google）。客戶端只與服務帳戶電子郵件共享特定的試算表或資料夾。完全不涉及個人帳戶。