GitHub 應用程式 vs. OAuth 應用程式：選擇合適的 GitHub 連接方式
比較 GitHub 應用程式與 OAuth 應用程式在 Logto 整合的應用。了解安全性、權限、權杖管理等主要差異，並選擇最適合你應用的 GitHub 驗證方式。
Product & Design
當你在 Logto 應用中整合 GitHub 驗證時，你有兩種選擇：GitHub 應用程式和 GitHub OAuth 應用程式。雖然兩者都能實現「使用 GitHub 登入」功能，但在安全性、權杖管理和 API 存取等方面提供本質上不同的體驗。本指南將幫助你了解它們的主要差異，並為你的使用情境選擇最合適的方法。
背景：連接 GitHub 的兩條路徑
Logto 現有的文件引導你建立 GitHub OAuth 應用程式 來進行社交登入。這是一個更簡單直接的選擇，非常適合基礎驗證需求。然而，GitHub 應用程式則是 GitHub 官方推薦的現代方法，提供增強的安全性及更細緻的控制。
你可以這麼想：OAuth 應用就像給別人你家的萬能鑰匙——只要授權就能全部進入。GitHub 應用則像智慧鎖系統，有不同房間的專屬密碼——用戶可以精確授權你的應用只取得必要的權限。
主要差異快速對比
權限：廣泛 vs. 細緻
- OAuth 應用程式 採用廣泛範圍——申請
repo範圍就可完全控制儲存庫。 - GitHub 應用程式 採用細緻權限——你可以只申請「議題：讀取」而不影響原始碼，用戶也可在安裝時選擇特定儲存庫，不需全面授權。
權杖安全性：永久 vs. 有效期
- OAuth 應用程式 發的權杖永不過期（除非手動撤銷），沒有刷新機制。
- GitHub 應用程式 發短效權杖（1 小時失效）並支援自動刷新——對長時間執行的應用更安全。
身分認證：用戶 vs. 機器人
- OAuth 應用程式 永遠以授權用戶的身分行事（例如：
@octocat），與用戶共享速率限制（5,000 請求／小時）。 - GitHub 應用程式 可以以自身機器人身分（如
@my-app[bot]）獨立操作，速率限制隨用量擴展——非常適合自動化。
存取控制：全有或全無 vs. 選擇性
- OAuth 應用程式 需一次授權訪問所有資源。
- GitHub 應用程式 讓用戶選擇安裝指定的儲存庫，且可收到權限變動的 webhook 通知——提供更好的透明度與掌控感。
持續性：依賴用戶 vs. 獨立運作
- OAuth 應用程式 綁定給授權用戶——如果該開發者失去權限或離開組織，應用將停止運作。
- GitHub 應用程式 即使安裝應用的開發者離開組織，仍會持續運作——確保自動化與整合不中斷。
如何選擇？
GitHub 應用程式和 OAuth 應用都能與 Logto 的社交連接元件無縫整合。Logto 的 Secret Vault 會安全儲存任一方案取得的權杖，但兩者體驗迥異：
基本社交登入：OAuth 應用程式
如果你只需驗證用戶（使用 GitHub 登入）且不會後續呼叫 GitHub API，OAuth 應用是最快捷徑：
- 設定簡單：用戶授權 OAuth 應用即可登入 GitHub。
- 權杖長效（無刷新）：Logto 會在 Secret Vault 儲存存取權杖，但無刷新流程 —— 權杖在未撤銷前一直有效。
- 適用於只需用戶資訊（信箱、姓名、頭像）且無自動化 API 工作的場景。
選擇理由：最適合原型或只需登入與偶爾同步資料的應用，部署速度最快。
進階整合：GitHub 應用程式
當你的應用需長期存取 GitHub API、進行背景自動化或需更高安全性時，請選擇 GitHub 應用：
- 超細緻權限與逐一安裝儲存庫選擇，確保權限最小化、可稽核性高。
- 權杖短效（通常 1 小時），GitHub 應用支援刷新權杖；啟用後 Logto 會存取、刷新兩種權杖，保持後端服務不因用戶重登入而中斷。
- 應用（機器人）身分提供歸因能力，且可享有可拓展速率限制，使自動化更可靠。
最佳適用對象：
- 代管用戶 GitHub 儲存庫的 SaaS 平台
- 需要與原始碼、議題或 PR 互動的 AI 代理人
- 需持續存取 API 的應用
- 執行背景自動化的工具
在 Logto 設定 GitHub 應用程式
GitHub 應用的設定方式與 OAuth 應用類似，僅有幾個關鍵差異。從 OAuth 應用升級到 GitHub 應用所需的遷移工作極少。
建立 GitHub 應用程式
-
前往「GitHub 設定 > 開發者設定 > GitHub 應用程式」
-
點擊「新增 GitHub 應用程式」
-
填寫：
- GitHub 應用名稱： 你的應用唯一識別名稱
- 首頁網址： 你的應用官方網站
- 回呼網址： 你的 Logto 連接元件回呼 URI（與 OAuth 應用相同）
- 安裝時請用戶授權（OAuth）： 請啟用
- Webhook： 選填，依需求決定
- 權限： 選擇細緻權限（如「議題：讀取」）
- 用戶權限： 如需代表用戶操作，可以新增帳號權限
-
產生用戶端密鑰（與 OAuth 應用相同）
在 Logto 進行設定
Logto 的連接元件設定基本一致 ：
- 填入 GitHub 應用的 Client ID
- 新增 Client secret
- 若需呼叫 GitHub API，啟用 「儲存權杖以持續存取 API」
- 一個關鍵差異 - 範圍（Scopes）：
- GitHub 應用的權限已在 GitHub 端設定，不需在 Logto 寫入 scope；相較之下 OAuth 應用必須於 Logto 輸入 scope。
- 請將 scope 欄位留空（GitHub 應用專屬）
- 申請刷新權杖（選填）
- 在 Logto 的 scope 欄位新增
offline_access以啟用刷新權杖 - GitHub 會自動簽發 refresh token，Logto 會自動輪替與儲存存取／刷新權杖
- 注意：OAuth 應用不支援刷新權杖——其 access token 永不過期，因此不適用
offline_access。這就是使用 GitHub 應用與整合時最大的不同。
- 在 Logto 的 scope 欄位新增
結論
雖然 OAuth 應用是基本驗證的有效途徑，GitHub 應用代表 GitHub 整合的未來。它們透過權杖到期、精細權限模型和更好的用戶控制，帶來卓越安全性。
對 Logto 用戶來說，兩種方式皆可接上社交連接。選擇取決於你的實際需求：
- 只需驗證，從 OAuth 應用開始
- 需要 API 操作、自動化或更高安全性時，升級到 GitHub 應用
別忘了——Logto 的 Secret Vault 和自動權杖刷新，讓 GitHub 應用管理權杖也像 OAuth 應用一樣簡單，還不用犧牲安全。不論你是在打造 AI 寫碼助理、專案管理平台或 開發者生產力工具，現在你已知如何為你的 Logto 應用選擇正確的 GitHub 整合方案。
準備好了嗎？立即參閱 Logto 的 GitHub 連接元件指南，開始整合 GitHub 驗證吧。