Skip to main content

OAuth アプリのスコープ

スコープによって、必要なアクセスの種類を正確に指定できます。 スコープによって OAuth トークンへのアクセスが 制限 されます。 ユーザがすでに持っている範囲を超えた権限を許可することはありません。

: OAuth app の代わりに GitHub App をビルドするのを考慮します。 GitHub Apps では、スコープではなくきめ細かいアクセス許可が使われるため、アプリで実行できる操作をより細かく制御できます。 詳細については、「GitHub Apps と OAuth アプリの違い」および「GitHub App の作成について」を参照してください。

OAuth app を GitHub 上でセットアップする際には、要求されたスコープが認可フォーム上でユーザに表示されます。

注: GitHub App を構築している場合は、認可要求でスコープを指定する必要はありません。 この詳細については、「ユーザーに代わって GitHub アプリで認証する」を参照してください。

CLIツールなど、OAuth appがブラウザにアクセスできない場合、アプリケーションを認可するユーザのスコープを指定する必要はありません。 詳しくは、「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 には、アクションがチェックするスコープが一覧表示されます。

利用可能なスコープ

名前説明
(no scope)パブリック情報 (ユーザー プロファイル情報、リポジトリ情報、gists を含む) repo
repo:statusパブリック、プライベート、内部リポジトリのコミット ステータスに対する読み取り/書き込みアクセスを許可します。 このスコープは、コードへのアクセスを許可 せずに、他のユーザーまたはサービスにプライベート リポジトリコミットステータスへのアクセス権を付与する場合にのみ必要です。
repo_deploymentパブリックおよびプライベート リポジトリのデプロイ ステータスに対するアクセスを許可します。 このスコープは、コードへのアクセスを許可 せずに、展開状態へのアクセス権を他のユーザーまたはサービスに付与する場合にのみ必要です。  public_repo
security_events補助 金:
code scanning API でのセキュリティ イベントに対する読み取りおよび書き込みアクセス
secret scanning API でのセキュリティ イベントに対する読み取りおよび書き込みアクセス
このスコープは、コードへのアクセスを許可 せずに、他のユーザーまたはサービスにセキュリティ イベントへのアクセス権を付与する場合にのみ必要です。 admin:repo_hook
write:repo_hookパブリック、プライベート、または内部リポジトリのフックに対する読み取り、書き込み、ping アクセスを許可します。
read:repo_hookパブリック、プライベート、または内部リポジトリのフックに対する読み取りおよび ping アクセスを許可します。
admin:orgOrganization とその Team、プロジェクト、メンバーシップを全面的に管理できます。
write:orgOrganization のメンバーシップ、Organization のプロジェクト、Team のメンバーシップに対する読み取りおよび書き込みアクセス。
read:orgOrganization のメンバーシップ、Organization のプロジェクト、Team のメンバーシップに対する読み取り専用アクセス。
admin:public_key公開鍵を全面的に管理できます。
write:public_key公開鍵の作成、一覧表示、詳細の表示ができます。
read:public_key公開鍵の一覧表示と詳細の表示ができます。
admin:org_hookOrganization フックに対する読み取り、書き込み、ping、削除アクセスを許可します。 注: OAuth トークンがこれらのアクションを実行できるのは、OAuth app によって作成された Organization フックに対してのみです。 Personal access token がこれらのアクションを実行できるのは、ユーザーが作成した組織のフックに対してのみです。
gistgist に対する書き込みアクセスを許可します。
notifications以下を許可します:
"ユーザーの通知に対する読み取りアクセス"
スレッドに対する既読としてマーク アクセス
"リポジトリに対するウォッチおよびウォッチ解除アクセス"
スレッドのサブスクリプションに対する読み取り、書き込み、削除アクセス。
userプロフィール情報のみに対する読み取り/書き込みアクセスを許可します。 このスコープには user:emailuser:follow が含まれることにご注意ください。
read:userユーザーのプロフィール データに対する読み取りアクセスを許可します。
user:emailユーザーのメール アドレスに対する読み取りアクセスを許可します。
user:follow他のユーザーをフォローまたはフォロー解除するためのアクセスを許可します。
projectユーザーおよび Organization の projects への読み取り/書き込みアクセスを許可します。
read:projectユーザーと組織 projects への読み取り専用アクセス権を付与します。 delete_repo
read:packagesGitHub Packages からパッケージをダウンロードまたはインストールするためのアクセスを許可します。 詳細については、「パッケージのインストール」を参照してください。
delete:packagesGitHub Packages からパッケージを削除するアクセス権を付与します。 詳しくは、「パッケージを削除および復元する」を参照してください。
admin:gpg_keyGPG キーを完全に管理できます。
write:gpg_keyGPG キーの作成、一覧表示、詳細の表示ができます。
read:gpg_keyGPG キーの一覧表示と詳細の表示ができます。
codespacecodespace の作成および管理権限を付与します。 codespace は、スコープのセットが異なる可能性がある GITHUB_TOKEN を公開する場合があります。 詳しくは、「GitHub Codespaces のセキュリティ」をご覧ください。 workflow
admin:enterpriseエンタープライズ機能の完全な制御権を付与します。 詳しくは、GraphQL API ドキュメントの「Enterpriseアカウントの管理」を参照してください。

manage_runners:enterprisemanage_billing:enterprise、および read:enterprise を含めます。
manage_runners:enterpriseEnterprise 内のセルフホステッド ランナーに対する完全な制御権を付与する。 詳しくは、「セルフホステッド ランナーの概要」を参照してください。
manage_billing:enterpriseエンタープライズ課金データの読み取りと書き込み。 詳しくは、REST API ドキュメントの「課金」をご覧ください。  read:enterprise

注: OAuth app は最初のリダイレクトでスコープを要求できます。 複数のスコープを指定するには、スコープを空白で区切ります (%20 を使用)。

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

リクエストされたスコープと許可されたスコープ

scope 属性は、トークンに付随する、ユーザーによって許可されたスコープを一覧表示します。 通常、これらのスコープはリクエストされたものと同じになります。 しかし、ユーザーはスコープを編集して、実質的には元々要求されたアクセスよりも少ないアクセスをアプリケーションに対して許可できます。 また、ユーザーは OAuth フローが完了した後にトークンのスコープを編集することもできます。 この可能性を認識しておき、それに応じたアプリケーションの動作の調整が必要になります。

元々要求されたアクセスよりも少ないアクセスをユーザーが許可した場合のエラー ケースを処理することが重要です。 たとえば、アプリケーションはユーザーに対して、機能の低下や一部のアクションが実行できないことを警告したり、知らせたりすることができます。

また、アプリケーションはいつでもユーザーをもう一度フローに戻して追加の権限を得ようとすることができますが、ユーザーは常に拒否できることを忘れないようにしてください。

変更できるトークンのスコープの扱いに関するヒントが提供されている認証の基本ガイドをご確認ください。

正規化されたスコープ

複数のスコープが要求された場合、トークンは正規化されたスコープのリストとともに保存され、要求された別のスコープに暗黙的に含まれているスコープは破棄されます。 たとえば user,gist,user:email を要求すると、トークンには usergist スコープのみが含まれます。これは、user:email スコープで許可されるアクセスは user スコープに含まれているからです。