跳到主要内容

OAuth 应用的范围

作用域允许您精确指定所需的访问类型。作用域限制OAuth 令牌的访问权限。它们不会授予超出用户已拥有权限的任何额外权限。

注意

建议构建 GitHub 应用而不是 OAuth 应用。GitHub 应用使用细粒度权限而不是作用域,这使您可以更好地控制应用可以执行的操作。更多信息,请参阅“GitHub 应用和 OAuth 应用之间的区别”和“关于创建 GitHub 应用”。

在 GitHub 上设置 OAuth 应用时,授权窗体中会向用户显示请求的作用域。

注意

如果您正在构建 GitHub 应用,则无需在授权请求中提供作用域。更多信息,请参阅“代表用户使用 GitHub 应用进行身份验证”。

如果您的 OAuth 应用无法访问浏览器(例如 CLI 工具),则无需为用户指定作用域以对其进行身份验证。更多信息,请参阅“授权 OAuth 应用”。

检查标头以查看您拥有的 OAuth 作用域以及 API 操作接受的作用域。

$ curl -H "Authorization: Bearer OAUTH-TOKEN" https://api.github.com/users/codertocat -I
HTTP/2 200
X-OAuth-Scopes: repo, user
X-Accepted-OAuth-Scopes: user
  • X-OAuth-Scopes 列出了您的令牌已授权的作用域。
  • X-Accepted-OAuth-Scopes 列出了操作检查的作用域。

可用作用域

名称描述
(无作用域)授予对公共信息(包括用户个人资料信息、存储库信息和 gist)的只读访问权限。
repo授予对公共和私有存储库的完全访问权限,包括对代码、提交状态、存储库邀请、协作者、部署状态和存储库 Webhook 的读写访问权限。注意:除了与存储库相关的资源外,repo 作用域还授予管理组织拥有的资源(包括项目、邀请、团队成员资格和 Webhook)的权限。此作用域还授予管理用户拥有的项目的权限。
repo:status授予对公共和私有存储库中提交状态的读写访问权限。此作用域仅在需要授予其他用户或服务对私有存储库提交状态的访问权限(无需授予对代码的访问权限)时才需要。
repo_deployment授予对公共和私有存储库的部署状态的访问权限。此作用域仅在需要授予其他用户或服务对部署状态的访问权限(无需授予对代码的访问权限)时才需要。
public_repo将访问权限限制为公共存储库。这包括对公共存储库和组织的代码、提交状态、存储库项目、协作者和部署状态的读写访问权限。还需要为加星标公共存储库。
repo:invite授予对协作存储库邀请的接受/拒绝权限。此作用域仅在需要授予其他用户或服务对邀请的访问权限(无需授予对代码的访问权限)时才需要。
security_events授予
代码扫描 API中安全事件的读写访问权限。
此作用域仅在需要授予其他用户或服务对安全事件的访问权限(无需授予对代码的访问权限)时才需要。
admin:repo_hook授予对公共或私有存储库中存储库钩子的读取、写入、ping 和删除访问权限。repopublic_repo 作用域授予对存储库(包括存储库钩子)的完全访问权限。使用 admin:repo_hook 作用域仅将访问权限限制为存储库钩子。
write:repo_hook授予对公共或私有存储库中钩子的读取、写入和 ping 访问权限。
read:repo_hook授予对公共或私有存储库中钩子的读取和 ping 访问权限。
admin:org完全管理组织及其团队、项目和成员资格。
write:org对组织成员资格和组织项目的读写访问权限。
read:org对组织成员资格、组织项目和团队成员资格的只读访问权限。
admin:public_key完全管理公钥。
write:public_key创建、列出和查看公钥的详细信息。
read:public_key列出和查看公钥的详细信息。
admin:org_hook授予对组织钩子的读取、写入、ping 和删除访问权限。注意:OAuth 令牌只能对 OAuth 应用创建的组织钩子执行这些操作。个人访问令牌只能对用户创建的组织钩子执行这些操作。
gist授予对 gist 的写入访问权限。
notifications授予
读取用户通知的访问权限
将线程标记为已读的访问权限
监视和取消监视存储库的访问权限,以及
读取、写入和删除线程订阅的访问权限。
user仅授予对个人资料信息的读写访问权限。请注意,此作用域包括user:emailuser:follow
read:user授予读取用户个人资料数据的访问权限。
user:email授予读取用户电子邮件地址的访问权限。
user:follow授予关注或取消关注其他用户的访问权限。
project授予对用户和组织项目的读写访问权限。
read:project授予对用户和组织项目的只读访问权限。
delete_repo授予删除可管理存储库的访问权限。
write:packages授予在 GitHub Packages 中上传或发布包的访问权限。更多信息,请参阅“发布包”。
read:packages授予从 GitHub Packages 下载或安装包的访问权限。更多信息,请参阅“安装包”。
delete:packages授予从 GitHub Packages 删除包的访问权限。更多信息,请参阅“删除和恢复包”。
admin:gpg_key完全管理 GPG 密钥。
write:gpg_key创建、列出和查看 GPG 密钥的详细信息。
read:gpg_key列出和查看 GPG 密钥的详细信息。
codespace授予创建和管理 codespace 的权限。Codespace 可以公开 GITHUB_TOKEN,后者可能具有不同的作用域集。更多信息,请参阅“GitHub Codespaces 中的安全”。
workflow授予添加和更新 GitHub Actions 工作流文件的权限。如果相同文件(具有相同的路径和内容)存在于同一存储库中的另一个分支中,则可以无需此作用域即可提交工作流文件。工作流文件可以公开GITHUB_TOKEN,后者可能具有不同的作用域集。更多信息,请参阅“自动令牌身份验证”。

注意

您的 OAuth 应用可以在初始重定向中请求作用域。您可以使用%20用空格分隔多个作用域。

https://github.com/login/oauth/authorize?
  client_id=...&
  scope=user%20repo_deployment

请求的作用域和授予的作用域

scope 属性列出了用户授予的附加到令牌的作用域。通常,这些作用域与您请求的作用域相同。但是,用户可以编辑其作用域,有效地向您的应用程序授予比您最初请求的更少的访问权限。此外,用户可以在完成 OAuth 流程后编辑令牌作用域。您应该意识到这种可能性并相应地调整应用程序的行为。

务必处理用户选择授予您比您最初请求的更少访问权限的错误情况。例如,应用程序可以警告或以其他方式与其用户通信,告知他们将看到功能减少或无法执行某些操作。

此外,应用程序始终可以再次将用户发送回流程以获取其他权限,但不要忘记用户始终可以拒绝。

查看身份验证基础指南,其中提供了有关处理可修改令牌作用域的技巧。

标准化作用域

请求多个作用域时,令牌将使用标准化作用域列表保存,并丢弃那些由另一个请求的作用域隐式包含的作用域。例如,请求user,gist,user:email将导致令牌仅具有usergist作用域,因为user:email作用域授予的访问权限包含在user作用域中。