Skip to main content

OAuth アプリの承認

GitHubのアイデンティティを、OAuth を使うサードパーティのアプリケーションに接続できます。 OAuth appを認可する際には、そのアプリケーションを信頼することを確認し、誰が開発したのかをレビューし、そのアプリケーションがどういった種類の情報にアクセスしたいのかをレビューしなければなりません。

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

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

OAuth appのアクセス

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

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

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

OAuth のスコープについて

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

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

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

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

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

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

データの種類説明
コミットのステータスアプリケーションにコミットのステータスをレポートするためのアクセスを許可できます。 コミットステータスのアクセスがあれば、アプリケーションはビルドが特定のコミットに対して成功したかどうかを判定できます。 アプリケーションはコードへのアクセスは持ちませんが、特定のコミットに対するステータス情報を読み書きできます。
デプロイメントデプロイメントのステータスへアクセスできれば、アプリケーションはパブリック及びプライベートのリポジトリの特定のコミットに対してデプロイメントが成功したかを判断できます。 アプリケーションはコードにはアクセスできません。
GistsGist アクセスでは、ユーザーのパブリック 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 セッションが必要です。

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

参考資料