# GitHub 应用与 OAuth 应用：选择合适的 GitHub 连接方式

当你在 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 的 密钥保险库 会安全保存任意一种方案的令牌，但每种体验是不同的：

用 OAuth 应用实现基础社交登录#

如果你只需要用户认证（即“使用 GitHub 登录”），且不会之后访问 GitHub API，那么 OAuth 应用是最快捷的路径：

• 设置简单：用户授权 OAuth 应用后即可通过 GitHub 登录。
• 令牌长期有效（不刷新）：Logto 可在保险库中存储访问令牌，但不存在刷新流程——令牌只要不被撤销就一直有效。
• 最适合只需要用户身份（邮箱、昵称、头像），无需自动化 API 操作的应用。

为什么选择这个方式：对于原型开发或只需登录与偶尔同步资料的应用，实现最快。

用 GitHub 应用实现增强集成#

当你的应用需要持续访问 GitHub API、后台自动化或更严格的安全时，应选择 GitHub 应用：

• 细粒度权限与基于安装的仓库选择，极限控制访问范围，操作可审计。
• 令牌时效短（通常 1 小时），GitHub 应用可提供刷新令牌；开启后 Logto 可保存访问令牌和刷新令牌，并自动轮换，无需用户再次登录即可保持后端服务运行。
• 应用身份（机器人）增强事件归因，速率限制可弹性扩容，重负载自动化更可靠。

最佳适用场景：

• 为用户统一管理 GitHub 仓库的 SaaS 平台
• 需要操作代码、议题、PR 的 AI 智能体
• 需要长期自动调用 API 的应用
• 后台自动化任务型工具

在 Logto 中配置 GitHub 应用#

设置 GitHub 应用的流程与 OAuth 应用类似，仅有少量差异。从 OAuth 应用迁移到 GitHub 应用，只需极少调整。

创建 GitHub 应用#

1. 前往 “GitHub 设置 > 开发者设置 > GitHub 应用”

2. 点击“新建 GitHub 应用”

3. 配置以下内容：

   • GitHub 应用名称： 你的应用唯一标识
   • 主页 URL： 你的应用官网
   • 回调 URL： 你的 Logto 连接器回调地址（与 OAuth 应用相同）
   • 安装时请求用户授权（OAuth）： 勾选启用
   • Webhook： 可选，按需配置
   • 权限： 选择细粒度权限（如“议题：只读”）
   • 用户权限： 若代表用户操作则添加账户权限

4. 生成 client secret（与 OAuth 应用相同）

在 Logto 中配置#

Logto 连接器配置几乎完全一致：

1. 输入你的 GitHub 应用 Client ID
2. 添加 Client secret
3. 如需持续访问 GitHub API，请启用 “为持久 API 访问存储令牌”
4. 关键不同点 - 作用域（Scopes）：
   • 不像 OAuth 应用（须在 Logto 的 scope 字段配置作用域），GitHub 应用权限直接在 GitHub 界面中勾选。
   • 在 Logto 填写时直接留空 scope 字段即可
5. 请求刷新令牌（可选）
   • 在 Logto 的 scope 字段添加 offline_access 开启刷新令牌
   • GitHub 自动下发刷新令牌，Logto 会自动轮换存储两种令牌至保险库
   • 注意：OAuth 应用本身不支持刷新令牌——访问令牌不会过期，因此 offline_access 不适用。而在 GitHub 应用集成时情况不同。

总结#

虽然 OAuth 应用依然适合基础认证场景，但 GitHub 应用代表了未来的 GitHub 集成方式。它带来了过期令牌带来的更高安全性、更精细的权限模型，以及用户对访问的更好控制。

对于 Logto 用户，两种方式都能通过社交连接器实现，最终选择哪种方案取决于你的实际需求：

• 只需认证可优先用 OAuth 应用
• 如需 API 访问、自动化或更高安全，建议升级用 GitHub 应用

请记住——Logto 的密钥保险库和自动令牌刷新，让 GitHub 应用的令牌管理和 OAuth 应用一样简单，同时不牺牲安全性。不论你在搭建 AI 编程助手、项目管理平台还是开发者工具，现在你都可以为 Logto 应用选择最合适的 GitHub 集成方式。

准备开始了吗？立刻查看 Logto 的 GitHub 连接器 ，马上集成 GitHub 认证。

附加资源#

• GitHub：GitHub 应用和 OAuth 应用的区别
• GitHub：将 OAuth 应用迁移到 GitHub 应用
• Logto：配置 GitHub 第三方社交登录
• Logto：第三方令牌存储与 API 访问
• GitHub：创建 GitHub 应用
• GitHub：OAuth 应用作用域说明