繁體中文（台灣）
  • GitHub
  • Secret vault
  • Token storage
  • OAuth
  • 社群登入

# GitHub 應用程式 vs. OAuth 應用程式：選擇合適的 GitHub 連線方式

比較 GitHub 應用程式和 OAuth 應用程式於 Logto 整合時的差異。了解在安全性、權限、權杖管理等方面的關鍵不同，幫助你為應用程式挑選正確的 GitHub 驗證方法。

Ran
Ran
Product & Design

不要在使用者認證上浪費數週時間
使用 Logto 更快地發布安全應用程式。幾分鐘內整合使用者認證，專注於您的核心產品。
立即開始
Product screenshot

當你在 Logto 應用程式整合 GitHub 驗證時，有兩種選擇：GitHub 應用程式和 GitHub OAuth 應用程式。雖然兩者都能實現「使用 GitHub 登入」功能，但在安全性、權杖管理及 API 存取等體驗上有本質的不同。本指南將協助你理解這些關鍵差異，並為你的需求選擇正確方法。

背景：兩條 GitHub 整合路徑

Logto 目前的文件會引導你建立一個 GitHub OAuth 應用程式 來做社群登入。這是最簡單且直接的方式，很適合基礎身份驗證需求。不過，GitHub 應用程式才是 GitHub 官方建議的現代整合方式，能帶來更高安全性與更細緻的控制權。

換個方式想：OAuth 應用程式就像給某人你家大門鑰匙，一經授權可進出所有空間。GitHub 應用程式則像智慧鎖系統，可對應不同房間分配特定密碼 —— 用戶能準確授予只屬於你應用需要的權限。

關鍵差異一覽

權限：寬鬆 vs. 細緻

  • OAuth 應用程式 採取較寬鬆的 scope —— 請求 repo 權限即能完全控制所有倉庫。
  • GitHub 應用程式 可申請細緻權限 —— 譬如僅要「議題：讀取」而不觸及程式碼。安裝時，使用者也能只選擇特定倉庫，而非全權開放。

權杖安全：永久有效 vs. 自動過期

  • OAuth 應用程式 發放永不過期的權杖（除非手動撤銷），沒有自動刷新機制。
  • GitHub 應用程式 則產生短效權杖（1 小時有效），並支援自動刷新 —— 對長時間運作的應用來說更加安全。

身份識別：用戶 vs. 機器人

  • OAuth 應用程式 永遠以授權用戶（例如 @octocat）身份行事，且共用相同的 API rate limit（5,000 次/小時）。
  • GitHub 應用程式 可以用自己的 bot 身份獨立行動（如 @my-app[bot]），隨著用量提升而擁有更高的頻率限制 —— 非常適合自動化服務。

存取控制：全有全無 vs. 彈性選擇

  • OAuth 應用程式 只需一次性授權就能存取所有開放資源。
  • GitHub 應用程式 允許用戶安裝應用、挑選特定倉庫，並收到權限變更的 webhook 通知 —— 讓存取更透明可控。

持續性：依賴用戶 vs. 獨立運作

  • OAuth 應用程式 綁定於授權用戶 —— 如果該開發者失去權限或離開組織，應用將停擺。
  • GitHub 應用程式 即使安裝者離開組織也能繼續運作 —— 確保自動化及整合不間斷。

該如何選擇？

GitHub 應用程式及 OAuth 應用程式都能無縫結合 Logto 的社群連接器。Logto 的 Secret Vault 會安全保存任一整合來源的權杖，但兩者帶來的體驗相當不同：

單純社群登入 —— OAuth 應用程式

只需驗證用戶（GitHub 登入），且日後不需呼叫 GitHub API，建議直接採用 OAuth 應用程式：

  • 設定簡單，用戶授權即可通過 GitHub 登入。
  • 權杖為長效型（無刷新）：Logto 只需儲存 access token，沒有刷新機制 —— 權杖有效至被撤銷。
  • 最適合僅需取得用戶資料（信箱、名稱、大頭貼）且無自動化 API 呼叫的情境。

選擇理由：開發原型或僅需單純登入、偶爾同步用戶檔案時最快速。

進階整合 —— GitHub 應用程式

若你的應用需長期存取 GitHub API、背景自動化或更嚴格安全性，請選擇 GitHub 應用程式：

  • 細緻權限管理及每次安裝挑選倉庫，權限最小、審核更便利。
  • 權杖為短效型（約 1 小時），且可支援刷新權杖；啟用後，Logto 會同時儲存 access 與 refresh token，自動處理輪替，後端服務無須要求用戶一再登入。
  • Bot 身份有助於紀錄來源及提升 API 頻率上限，適合大量自動化需求。

最適合：

  • 代表用戶管理 GitHub 倉庫的 SaaS 平台
  • 會與程式碼、議題或拉取請求互動的 AI agent
  • 需長期 API 存取的應用系統
  • 執行背景自動化任務的工具

在 Logto 建立 GitHub 應用程式

建立 GitHub 應用程式的流程和 OAuth 應用類似，僅有幾處關鍵差異。從 OAuth 應用程式轉移到 GitHub 應用程式幾乎不需額外工夫。

建立 GitHub 應用程式

  1. 前往「GitHub 設定 > 開發者設定 > GitHub 應用程式」

  2. 點選「新建 GitHub 應用程式」

  3. 設定：

    • GitHub 應用程式名稱： 你的應用獨一無二的識別名稱
    • 首頁網址： 你的程式網站
    • 回呼網址： Logto 連線器 callback URI（與 OAuth 應用相同）
    • 安裝時請求用戶授權（OAuth）： 請勾選啟用
    • Webhook： 視需求是否啟用
    • 權限： 選取細緻權限（如「議題：讀取」）
    • 用戶權限： 若需代表用戶操作，請新增帳號權限

  4. 產生 client secret（與 OAuth 應用相同）

integrate-github-apps.png

在 Logto 設定

Logto 的連線器設定幾乎完全相同：

  1. 輸入 GitHub 應用程式的 Client ID
  2. 填入 Client secret
  3. 若需呼叫 GitHub API，請啟用 「儲存權杖以持續 API 存取」
  4. 關鍵差異 - Scopes 欄位：
    • 和 OAuth 應用不同，GitHub 應用程式權限需在 GitHub 應用後台設定，Logto 這邊不需額外填寫 scopes。
    • 請將 Logto 的 scopes 欄留空即可
  5. 申請刷新權杖（可選）
    • 如需啟用 refresh token，請在 Logto scopes 欄輸入 offline_access
    • GitHub 會自動發放 refresh token，Logto 將自動儲存及輪替 access/refresh token
    • 注意：OAuth 應用程式不支援刷新權杖 —— 它們的 access token 永不過期，因此 offline_access 無效。這與 GitHub 應用串接的情況不同。

integrate-github-connector-in-logto.png

結論

雖然 OAuth 應用程式在基本身份驗證情境下仍然適用，但 GitHub 應用程式是未來的主流整合方式。它們透過權杖過期機制實現更高資安、精細權限與更好的用戶存取控制。

對 Logto 用戶來說，兩種方案都符合社群連接器的需求。選擇重點如下：

  • 只需認證時請選 OAuth 應用程式
  • 需 API、自動化或高安全時建議用 GitHub 應用程式

記得 —— Logto 的 Secret Vault 及自動權杖刷新機制讓管理 GitHub 應用程式權杖和管理 OAuth 權杖一樣簡單，同時又不犧牲安全性。無論你正在開發 AI 程式助理、專案管理平台或開發者生產力工具，現在你已具備為 Logto 應用選對 GitHub 整合方式的知識。

準備好開始了嗎？前往 Logto GitHub 連線器教學 即刻啟用 GitHub 登入。

進階資源