Skip to main content

OAuth アプリの承認

OAuth を使用して、 GitHub ID をサードパーティのアプリケーションに接続できます。 OAuth appを承認するときは、アプリケーションを信頼し、そのアプリケーションの開発元を確認し、アプリケーションがアクセスする情報の種類を確認する必要があります。

OAuth appがGitHubのアカウントでユーザーを識別する必要がある場合は、アプリの開発者の連絡先情報と、要求されている特定のデータの一覧が表示されます。

ヒント

を承認する前に、OAuth appする必要があります。

OAuth app アクセス

OAuth appsは、__ データへの_読み取_りまたはGitHubアクセス権を持つことができます。

  • 読み取りアクセスでは、アプリがデータを_参照_することのみ可能です。
  • 書き込みアクセスでは、ユーザーのデータの "変更" が可能です。

ヒント

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

OAuth のスコープについて

スコープ は、パブリック データと非パブリック データの両方へのアクセスを OAuth app が要求できるアクセス許可の名前付きグループです。

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

メモ

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

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

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

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

OAuth apps では、複数の種類のデータを要求できます。

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

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

新しいアクセス許可 OAuth apps 要求すると、現在のアクセス許可と新しいアクセス許可の違いについて通知されます。

OAuth apps および組織

個人アカウントの OAuth app を承認すると、その承認がメンバーになっている各組織に与える影響も確認できます。

  • アクセス制限__OAuth app組織の場合は、組織の所有者がその組織で使用するアプリケーションを承認することを要求できます。 Organization からアプリケーションの承認が受けられない場合、アプリケーションによるアクセスは、Organization のパブリック リソースに限られます。 組織管理者であれば、自分でアプリケーションを承認できます。

  • アクセス制限OAuth app組織の場合、アプリケーションには、その組織のリソースへのアクセスが自動的に承認されます。 このため、個人アカウント リソースと組織リソースへのアクセスを承認する OAuth apps に注意する必要があります。

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

メモ

SAML によって保護されている組織にアクセスする承認されたOAuth appまたはGitHub Appで問題が発生した場合は、承認されたGitHub AppsまたはOAuth apps ページからアプリを取り消し、組織にアクセスして認証し、アクティブな SAML セッションを確立し、アクセスしてアプリの再認証を試みる必要があります。

参考資料