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 和删除访问权限。`repo` 和 `public_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:email` 和 `user: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将仅生成包含user和gist范围的令牌，因为user:email范围授予的访问权限已包含在user范围中。

本文内容

可用范围

请求的范围和授予的范围

规范化范围