GitHub 应用 vs. OAuth 应用：选择适合你 GitHub 连接方式

当你在 Logto 应用中集成 GitHub 认证时，有两种选择：GitHub 应用以及 GitHub OAuth 应用。虽然两者都能实现“使用 GitHub 登录”的功能，但在安全、令牌管理和 API 访问方面，它们带来的是截然不同的体验。本指南将帮助你理解关键差异，并为你的使用场景选择正确的方式。

背景：GitHub 集成的两条路径#

Logto 现有的文档会指导你搭建一个 GitHub OAuth 应用 用于社交登录。这是更简单、直接的方法，非常适合基本认证需求。而 GitHub 应用则是 GitHub 官方推荐的现代集成方式，增强了安全性并拥有更精细的控制。

换个角度理解：OAuth 应用就像给某人一把你家房子的万能钥匙——授权后他们拥有广泛访问权限。GitHub 应用则像智能门锁系统，你可以为不同房间设置专属密码码——用户只能授权你 app 需要的具体权限。

关键信息速览#

权限：广泛 vs. 细粒度#

• OAuth 应用 使用广泛的作用域（scope）——如请求 repo 就能获得完整仓库控制权。
• GitHub 应用 支持细粒度权限——比如你可以只请求“议题：只读”权限，而不访问代码。在安装时用户可选择特定仓库，而不是全部授权。

令牌安全：永久 vs. 临时#

• OAuth 应用 颁发从不自动过期的令牌（除非手动吊销），且没有刷新机制。
• GitHub 应用 使用短时令牌（通常 1 小时内过期），支持自动刷新——让长期运行的应用更加安全。

身份：用户 vs. 机器人#

• OAuth 应用 始终以授权用户（例如 @octocat）身份操作，且与用户共用速率限制（5,000 次请求/小时）。
• GitHub 应用 可以独立以自身机器人（如 @my-app[bot]）身份运行，根据应用使用量速率限制可扩容——非常适合自动化场景。

访问控制：全或无 vs. 精细选择#

• OAuth 应用 需一次性授权所有可访问资源。
• GitHub 应用 允许用户安装 app 时选择特定仓库，并收取权限变动的 webhook 通知——实现更好的透明度和控制力。

持久性：依赖用户 vs. 独立存活#

• OAuth 应用 与授权用户绑定——如果开发者失去访问权限或离开组织，app 就不能用了。
• GitHub 应用 即便安装 app 的开发者离开组织也能继续运行——保证自动化和集成服务的不间断。

应该选择哪个？#

GitHub 应用和 OAuth 应用都能无缝适配 Logto 的社交连接器。Logto 的 机密库 可安全存储任一集成下获取的令牌，但两者体验截然不同：

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

如果你只需要用户认证（用 GitHub 登录），且后续不会调用 GitHub API，最简便的方式就是用 OAuth 应用：

• 配置简单：用户授权 OAuth 应用，即可使用 GitHub 登录。
• 长效令牌（无刷新机制）：Logto 可以把访问令牌保存到机密库，但不会走刷新逻辑——令牌一直有效直到吊销。
• 适合只需要用户身份（邮箱、名称、头像）的场景，不通过自动化调用 API。

为何选它：拿来做原型、只需登录或偶尔同步资料的应用，开发最快。

用 GitHub 应用实现深度集成#

如果你的程序要持续访问 GitHub API、实现后台自动化，或强化安全需求，请选择 GitHub 应用：

• 细粒度权限+逐安装选择仓库，让访问权限最小化且方便审计。
• 令牌生命周期短（通常 1 小时），可获取刷新令牌；启用后，Logto 会同时存储访问令牌与刷新令牌并自动刷入，后端服务无需用户重复登录。
• App 身份（机器人）增强归因，且更高速率限制让自动化任务更稳定可靠。

最佳适用场景：

• 代表用户管理 GitHub 仓库的 SaaS 平台
• 需要操作代码、议题、PR 的 AI 智能体
• 长期访问 GitHub API 的应用
• 执行后台自动化任务的工具

在 Logto 设置 GitHub 应用#

配置 GitHub 应用和 OAuth 应用步骤类似，有一些关键差异。从 OAuth 应用迁移到 GitHub 应用过程也十分轻松。

创建 GitHub 应用#

1. 访问“GitHub 设置 > 开发者设置 > GitHub 应用”

2. 点击“新建 GitHub 应用”

3. 配置：

   • GitHub 应用名称： 你应用的唯一标识
   • 主页 URL： 你应用的网站地址
   • 回调 URL： 你 Logto 连接器的回调地址（与 OAuth 应用保持一致）
   • 安装时请求用户授权（OAuth）： 勾选
   • Webhook： 选配，根据需求设置
   • 权限： 选择细粒度权限（如“议题：只读”）
   • 用户权限： 如果要以用户身份操作可设置账号权限

4. 生成客户端密钥（和 OAuth 应用一样）

在 Logto 里配置#

Logto 连接器的配置步骤几乎一样：

1. 输入你 GitHub 应用的 客户端 ID
2. 填写 客户端密钥
3. 启动 “存储令牌以持久访问 API”，如果你需要调用 GitHub API
4. 关键差异 - Scope（权限）：
   • 不像 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 应用的作用域