OAuth アプリの承認

OAuth app から GitHub のアカウントによる識別を求められた場合、アプリの開発者の連絡先情報と要求されている特定のデータのリストが記載されたページが表示されます。

Tip

OAuth app を認可する前に、メールアドレスを確認する必要があります。

OAuth appのアクセス

OAuth apps は、ユーザーの GitHub データへの "読み取り" アクセスまたは "書き込み" アクセスを行うことができます。

読み取りアクセスでは、ユーザーのデータの "閲覧" のみ可能です。
書き込みアクセスでは、ユーザーのデータの "変更" が可能です。

Tip

認可されたインテグレーションを定期的にレビューすることをおすすめします。しばらくの間使われていないアプリケーションやトークンは削除してください。詳しくは、「承認された OAuth アプリをレビューする」を参照してください。

OAuth のスコープについて

"スコープ" は、権限の名前付きグループです。これは、OAuth app がパブリックデータと非パブリックデータへのアクセスをリクエストできるという権限です。

GitHubと統合される OAuth appを使用したい場合、そのアプリケーションはデータに対してどういった種類のアクセスが必要になるのかを知らせてきます。アプリケーションにアクセスを許可すれば、アプリケーションはあなたの代わりにデータの読み取りや変更といったアクションを行えるようになります。たとえば、user:email スコープを要求するアプリを使用する必要がある場合、アプリは個人用メールアドレスへの読み取り専用アクセス権を持つことになります。詳しくは、「OAuth アプリのスコープ」をご覧ください。

Note

現在、ソースコードのアクセスのスコープを読み取り専用に設定することはできません。

トークンは、トークンのオーナーと同様に、リソースにアクセスしてそれらのリソースに対してアクションを実行できますが、さらに、トークンに付与されるスコープまたはアクセス許可によって制限されます。トークンは、ユーザーに追加のアクセス権を付与できません。たとえば、アプリケーションは、admin:org スコープで構成されたアクセストークンを作成できますが、アプリケーションのユーザーが Organization のオーナーでない場合、アプリケーションには Organization への管理アクセス権は付与されません。

ユーザー/アプリケーション/スコープの組み合わせごとに、1 時間あたり作成されるトークン数には 10 という上限があります。アプリケーションで同じユーザーと同じスコープに対して 10 個を超えるトークンが作成された場合、同じユーザー/アプリケーション/スコープの組み合わせを持つ最も古いトークンが取り消されます。ただし、時間単位のレート制限に達しても、最も古いトークンは取り消されません。代わりに、ブラウザー内で再承認プロンプトがトリガーされ、ユーザーはアプリに付与しているアクセス許可を再確認するよう求められます。このプロンプトは、アプリが 1 時間以内にユーザーに 10 個のトークンを要求する理由がほとんどないため、アプリが陥っている可能性のある無限ループを中断させることを目的としています。

リクエストされるデータの種類

OAuth apps がリクエストできるデータは、数種類あります。

データの種類	説明
コミットのステータス	アプリケーションにコミットのステータスをレポートするためのアクセスを許可できます。コミットステータスのアクセスがあれば、アプリケーションはビルドが特定のコミットに対して成功したかどうかを判定できます。アプリケーションはコードへのアクセスは持ちませんが、特定のコミットに対するステータス情報を読み書きできます。
デプロイメント	デプロイメントのステータスへアクセスできれば、アプリケーションはパブリック及びプライベートのリポジトリの特定のコミットに対してデプロイメントが成功したかを判断できます。アプリケーションはコードにはアクセスできません。
Gists	Gist アクセスでは、ユーザーのパブリック Gist とシークレット Gist の両方への、アプリによる読み取りや書き込みが可能です。
フック	Webhook アクセスでは、管理するリポジトリのフック構成への、アプリによる読み取りや書き込みが可能です。
通知	通知アクセスがあれば、アプリケーションは Issue やプルリクエストへのコメントなど、あなたの GitHub通知を読むことができます。しかし、アプリケーションはリポジトリ内へはアクセスできないままです。
組織とチーム	Organization および Team のアクセスがあれば、アプリケーションは Organization および Team のメンバー構成へのアクセスと管理ができます。
ユーザーの個人データ	ユーザデータには、名前、メールアドレス、所在地など、ユーザプロファイル内の情報が含まれます。
リポジトリ	リポジトリ情報には、コントリビュータの名前、あなたが作成したブランチ、リポジトリ内の実際のファイルなどが含まれます。アプリケーションはユーザ単位のレベルでパブリックあるいはプライベートリポジトリへのアクセスをリクエストできます。
リポジトリの削除	アプリケーションはあなたが管理するリポジトリの削除をリクエストできますが、コードにアクセスすることはできません。
プロジェクト	ユーザーおよび Organization の projects へのアクセス。アプリでは、読み取りおよび書き込みアクセスか、読み取り専用アクセスのいずれかを要求できます。

更新された権限のリクエスト

OAuth apps によって新しいアクセス権限がリクエストされると、現在の権限と新しい権限の違いが知らされます。

OAuth apps と Organization

個人用のユーザーアカウントで OAuth app を承認する場合、自分がメンバーになっている各 Organization がどのように影響を受けるかについてもわかります。

OAuth app のアクセス制限が "ある" 組織の所有者の場合、その組織でのアプリケーションの使用の承認を組織管理者にリクエストできます。 Organization からアプリケーションの承認が受けられない場合、アプリケーションによるアクセスは、Organization のパブリックリソースに限られます。組織管理者であれば、自分でアプリケーションを承認できます。
OAuth app のアクセス制限が "ない" Organization の場合、このアプリケーションによるその Organization のリソースへのアクセスは自動的に承認されます。 このため、すべての Organization リソースはもとより、個人用アカウントリソースへのアクセスが承認されている OAuth apps については、注意を払う必要があります。

SAML シングルサインオン (SSO) が有効になっている組織に属していて、過去に SAML 経由で認証することでその組織のリンクされた ID を作成した場合は、OAuth app を承認するたびに、各組織に対してアクティブな SAML セッションが必要です。