跳至主要內容

第三方應用程式（OAuth / OIDC）

Logto 的第三方應用程式整合功能，讓你能將 Logto 作為外部應用程式的 身分提供者 (IdP, Identity Provider)。

身分提供者 (IdP) 是一種驗證使用者身分並管理其登入憑證的服務。確認使用者身分後，IdP 會產生驗證權杖或斷言，並允許使用者存取各種應用程式或服務，而無需再次登入。

與你在 將 Logto 整合到你的應用程式 指南中建立、由你完全控制的應用程式不同，第三方應用程式是由外部開發者或商業夥伴開發的獨立服務。

這種整合方式非常適合常見的商業場景。你可以讓使用者用 Logto 帳號登入合作夥伴的應用程式，就像企業用戶用 Google Workspace 登入 Slack 一樣。你也可以打造一個開放平台，讓第三方應用程式新增「使用 Logto 登入」功能，類似「使用 Google 登入」。

Logto 是一個基於 OpenID Connect (OIDC) 協議的身分服務，提供 驗證 (Authentication) 與 授權 (Authorization) 能力。這讓 OIDC 第三方應用程式的整合就像傳統 Web 應用程式一樣簡單。

由於 OIDC 建立於 OAuth 2.0 之上，並新增了驗證層，因此你也可以使用 OAuth 協議整合第三方應用程式。

導入第三方應用程式的兩種方式​

  • 在 Logto 註冊應用程式（本指南）：你建立應用程式並設定其權限與重導 URI。適用於你已知合作夥伴的情境。
  • 動態應用程式：客戶端無需預先註冊，直接使用公開 HTTPS URL 作為 client ID，該 URL 提供自己的 metadata 文件。適用於任何客戶端都可能連線的情境，例如 MCP 客戶端與 AI agent。

兩種方式可同時使用。

在 Logto 建立第三方應用程式​

  1. 前往 控制台 > 應用程式。
  2. 點擊「建立應用程式」按鈕，選擇「第三方應用程式」作為應用程式類型，並選擇以下其中一種整合協議：
    • OIDC / OAuth
  3. 根據第三方應用程式的型態選擇應用程式類型：
    • 傳統 Web：伺服器端渲染的應用程式（如 Node.js、PHP、Java），可安全儲存 client secret。
    • 單頁應用程式 (SPA)：前端渲染的應用程式（如 React、Vue、Angular），完全在瀏覽器執行，無法安全儲存密鑰。
    • 原生應用程式 (Native)：行動或桌面應用程式（如 iOS、Android、Electron），在使用者裝置上執行。
  4. 輸入應用程式名稱與描述，點擊「建立」按鈕，即可建立新的第三方應用程式。

所有建立的第三方應用程式都會在「應用程式」頁面的「第三方應用程式」分頁下分類顯示。這樣有助於你區分自有應用程式與第三方應用程式，方便統一管理。

若要限制哪些使用者能登入第三方應用程式，請在應用程式的 規則 (Rules) 分頁設定 應用程式層級存取控制。

整合指南​

查找應用程式設定資訊​

在應用程式詳細頁面，你可以找到整合所需的 Client ID、Client secret（僅限傳統 Web 應用程式）以及 OIDC 端點。

若第三方服務支援 OIDC discovery，只需提供 Discovery endpoint。否則，點擊 顯示端點詳情 可查看所有端點，包括 授權端點 與 權杖端點。

整合支援第三方 IdP 的服務​

若你要連接的服務或產品原生支援外部身分提供者設定（如企業級 SaaS 平台、協作工具），設定流程如下：

  1. 開啟服務的 IdP 或 SSO 設定頁面。
  2. 從 Logto 複製 Client ID（如需則包含 Client secret），貼到服務的設定中。
  3. 若服務支援 OIDC 自動發現，提供 Discovery endpoint；否則手動複製 授權端點 與 權杖端點。
  4. 從服務設定頁複製 Redirect URI，並加入 Logto 應用程式允許的 redirect URI 清單。
  5. 若服務允許，設定 scopes。Logto 為 OIDC 提供者，若需驗證使用者請包含 openid 權限範圍（可取得 ID 權杖與 UserInfo 端點）。若僅需 OAuth 資源存取，openid 權限範圍為選填。

服務設定完成後，將自動處理 OAuth / OIDC 流程。

透過 OAuth / OIDC 協議整合​

若第三方應用程式需以程式方式將 Logto 作為 IdP 整合，應實作標準的 授權碼流程 (Authorization Code Flow)。建議使用你所用程式語言的 OAuth 2.0 / OIDC client library 來實作。

傳統 Web 應用程式屬於 機密客戶端 (confidential clients)，可安全儲存 client secret。完整實作細節請參考 授權碼流程 (Authorization Code Flow)。

主要步驟：

  1. 啟動授權：將使用者導向 Logto 的授權端點，帶上 client_id、redirect_uri、response_type=code 與 scope。
  2. 處理回調：從 redirect 接收授權 code。
  3. 交換權杖：從後端以 POST 請求帶上 code、client_id 與 client_secret 到權杖端點。

透過裝置流程整合​

對於運行於輸入受限裝置（如智慧電視、遊戲主機、CLI 工具）的原生第三方應用程式，標準的重導向授權碼流程可能不適用。此時可改用 OAuth 2.0 裝置授權流程 (Device Authorization Grant)。

裝置流程會在裝置上顯示一組使用者代碼與驗證網址。使用者在另一台裝置（手機、筆電）上造訪該網址，輸入代碼並完成驗證。裝置則持續輪詢 Logto 的權杖端點，直到授權完成。

備註:

在實作裝置流程前，請先於 Logto 控制台為你的第三方應用程式設定所需的 權限。第三方應用程式若請求未啟用的權限範圍將被拒絕存取。

完整實作細節請參考 裝置流程快速入門。

出於安全考量，所有 OIDC 第三方應用程式在經 Logto 驗證後，將被導向 使用者授權頁面 (Consent screen) 進行授權。

所有第三方請求的 使用者資料權限、API 資源權限範圍、組織權限 及組織成員資訊都會顯示於授權頁面。

這些請求的權限僅在使用者點擊「授權」按鈕後才會授予第三方應用程式。

consent screen

進階操作​

常見問題​

Logto 透過基於角色的存取控制 (RBAC, Role-Based Access Control) 管理使用者權限。在授權頁面上，僅會顯示已透過角色分配給使用者的權限範圍（scopes）。若第三方應用程式請求使用者未擁有的權限範圍，這些權限將不會顯示，以防止未授權的授權行為。

管理方式如下：

  • 定義具有特定權限範圍的 全域角色 或 組織角色。
  • 根據存取需求將角色分配給使用者。
  • 使用者將自動繼承其角色的權限範圍。

使用案例：整合 Apache Answer 為你的用戶打造社群

 使用 Logto 作為第三方身分提供者 (IdP)