Apps と OAuth apps について
通常、 Apps が OAuth apps より優先されます。 Apps では、きめ細かいアクセス許可が使われ、アプリでアクセスできるリポジトリをより細かく制御でき、有効期間の短いトークンが使われます。 これらの特徴により、アプリの資格情報が漏洩した場合に発生する可能性のある損害を制限することで、アプリのセキュリティを強化できます。
OAuth apps と同様に、 Apps でも引き続き OAuth 2.0 を使って、OAuth トークンの種類 (別名、ユーザー アクセス トークン) を生成し、ユーザーに代わってアクションを実行できます。 ただし、 Apps は、ユーザーとは関係なく動作することもできます。 これは、ユーザー入力を必要としない自動化に役立ちます。 アプリを Organization にインストールしたユーザーが Organization からいなくなった場合でも、アプリは引き続き機能します。
Apps には、一元化された Webhook が組み込まれています。 Apps は、アプリでアクセスできるすべてのリポジトリおよび組織の Webhook イベントを受け取ることができます。 逆に、OAuth apps では、リポジトリと組織ごとに個別に Webhook を構成する必要があります。
インストール アクセス トークンを使う Apps のレート制限は、リポジトリの数と組織のユーザーの数に応じてスケーリングされます。 逆に、OAuth apps のレート制限は低く、スケーリングされません。
App より OAuth app の方が推奨されるケースが 1 つあります。 Enterprise オブジェクトなど、Enterprise レベルのリソースにアプリからアクセスする必要がある場合、 App ではまだ Enterprise に対してアクセス許可を付与できないため、OAuth app を使う必要があります。 Apps では、エンタープライズが所有する組織とリポジトリ リソースに引き続きアクセスできます。
Apps の詳細については、「 App の作成について」を参照してください。
既存の OAuth app の App への移行の詳細については、「OAuth アプリから Appへの移行」を参照してください。
Apps をインストールし、OAuth appsを承認できるのは誰ですか?
App は、個人アカウントおよび自分が所有する Organization にインストールできます。 リポジトリの管理者権限がある場合には、 App を Organization のアカウントにインストールできます。 App がリポジトリにインストールされていて、Organization の権限を要求している場合、Organization のオーナーはアプリケーションを承認する必要があります。
デフォルトでは、Organization内の Appsの設定を管理できるのはOrganizationのオーナーだけです。 組織が所有する Apps の開発者設定を追加ユーザーが変更できるようにするため、所有者は App マネージャーのアクセス許可を付与できます。 App マネージャーは、サード パーティのアプリケーションを管理できません。 Organization での App マネージャーの追加と削除の詳細については、「Organizationのロール」を参照してください。
一方、ユーザーが OAuth appsを承認すると、認証されたユーザーとして動作する機能がアプリに提供されます。 たとえば、認証済みのユーザーに対するすべての通知を検索する OAuth appを承認できます。 アクセス許可は、OAuth appからいつでも取り消すことができます。
Organization の所有者は、外部コラボレーターが承認されていない OAuth apps と Apps へのアクセスを要求できるようにするかどうかを選べます。 詳しくは、「OAuth アプリと App のアクセス要求を制限する」をご覧ください。
警告
OAuth app からすべてのアクセス許可を取り消すと、ユーザーの代わりにアプリケーションで生成されたすべての SSH キー (配置キーを含む) が削除されます。
| アプリ | OAuth apps |
|---|---|
| Organization に App をインストールするには、Organization のオーナーであるか管理者権限を所有している必要があります。 App がリポジトリにインストールされていて、Organization の権限を要求している場合、Organization のオーナーはアプリケーションを承認する必要があります。 | OAuth appにリソースへのアクセス権を承認できます。 |
| App は個人のリポジトリにインストールできます。 | OAuth appにリソースへのアクセス権を承認できます。 |
| App をアンインストールしてアクセス権限を削除するには、Organization のオーナーであるか、個人リポジトリの所有者であるか、リポジトリの管理者権限を所有している必要があります。 | OAuth アクセストークンを削除して、アクセス権限を削除することができます。 |
| App のインストールを要求するには、Organization のオーナーであるかリポジトリの管理者権限を所有している必要があります。 | Organization のアプリケーション ポリシーが有効な場合、その Organization のすべてのメンバーが、Organization への OAuth appのインストールを要求できます。 Organization のオーナーは、その要求を承認または拒否する必要があります。 |
Apps と OAuth appsがアクセスできる内容
アカウントの所有者は、別のアカウントにアクセス権限を与えることなく App を使用できます。 たとえば、サードパーティ製のビルドサービスを従業員の Organization にインストールしつつ、そのビルドサービスに個人アカウントにあるリポジトリへのアクセスを許可しないことができます。 App をセットアップした人が Organization から離れても、その App はインストールされたままになります。
"承認済み" の OAuth appには、ユーザーまたは Organization の所有者がアクセス可能なすべてのリソースへのアクセス権があります。__
| アプリ | OAuth apps |
|---|---|
| アプリをインスールすると、アプリはユーザーまたは組織アカウントの選択されたリポジトリにアクセスできるようになります。 | OAuth appを承認すると、ユーザーがアクセスできるリソースへのアクセスがアプリに付与されます。 たとえば、リポジトリにアクセスできます。 |
| 管理者がインストールからリポジトリを削除した場合、 App のインストールトークンはリソースにアクセスできなくなります。 | リポジトリへの書き込みアクセスを失ったときなど、ユーザがアクセスを失ったとき、OAuth アクセストークンはリソースにアクセスできなくなります。 |
| インストール アクセス トークンは、アプリケーションの作成者が選択したアクセス許可を所有する、指定されたリポジトリに制限されます。 | OAuth アクセス トークンは、スコープで制限されます。 |
| App は、リポジトリの実際のコンテンツにアクセスすることなく、Issue やプルリクエストへの個別のアクセスを要求できます。 | OAuth appsは、issue、pull request、またはリポジトリが所有するすべてのものにアクセスするために、repo スコープを要求する必要があります。 |
| アプリは組織のアプリケーション ポリシーの対象ではありません。 アプリは組織の所有者が許可したリポジトリにのみアクセスできます。 | Organization のアプリケーション ポリシーがアクティブな場合、Organization の所有者のみが OAuth appのインストールを認可できます。 インストールされている場合、OAuth appは承認された Organization 内で Organization の所有者が所持しているトークンで表示できるすべてのものにアクセスできます。 |
| App は、インストールが変更または削除されると webhook イベントを受信します。 これにより、アプリケーションの作者は、 App の Organization のリソースに対するアクセス権が変更されたことがわかります。 | OAuth appsは、許可ユーザーのアクセス権が変更されると、それに基づき、組織やリポジトリへのアクセス権を失う場合があります。 リソースへのアクセスを失った場合、OAuth appにより通知はされません。 |
トークンベースの識別
メモ
アプリでは、ユーザー ベースのトークンを使用することもできます。 詳しくは、「ユーザーに代わって アプリで認証する」をご覧ください。
| アプリ | OAuth apps |
|---|---|
| App は、JSON Web トークンフォーマットのアウトオブバンドで秘密鍵を使用することにより、インストールアクセストークンをリクエストできます。 | OAuth appは、Web リクエストを通じたリダイレクトの後に要求トークンをアクセス トークンに交換できます。 |
| インストール トークンは、アプリを アプリのボット (@jenkins-bot など) として識別します。 | アクセス トークンは、アプリをそのアプリにトークンを付与したユーザー (@octocat など) として識別します。 |
| インストール アクセス トークンは、事前に定義された時間 (現在は 1 時間) が経過すると期限切れになります。 | OAuth トークンは、顧客によって取り消されるまで有効となります。 |
| Organization またはリポジトリにインストールされた Appsは、インストール数に応じてスケーリングされるレート制限の対象となります。 詳しくは、「Rate limits for Apps ( アプリのレート制限)」をご覧ください。 | OAuth トークンでは、1 時間あたり要求 5,000 件というユーザーのレート制限が使用されます。 |
| レート制限の増加は、 アプリ レベル (すべてのインストールに影響) と個々のインストール レベルの両方で許可できます。 | レート制限の引き上げは、OAuth appごとに付与されます。 その OAuth appに付与されたすべてのトークンの制限が引き上げられます。 |
| Apps では、ユーザーの代わりに認証を行うことができます。 認可するフローは OAuth app の認可フローと同じです。 ユーザー アクセス トークンは期限切れになることがあり、更新トークンで更新できます。 詳細については、「ユーザー アクセス トークンを更新する」および「ユーザーに代わって アプリで認証する」を参照してください。 | OAuth apps により使用される OAuth フローでは、ユーザの代わりに OAuth app を承認します。 これは、 App ユーザー アクセス トークンの生成に使用されるフローと同じです。 |
リソースに対する権限レベルのリクエスト
OAuth appsとは異なり、 App には必要なアクセス権のみをリクエストできる、ターゲットを絞った権限があります。 たとえば、継続的インテグレーション (CI) App は、リポジトリコンテンツへの読み取りアクセスと、ステータス API への書き込みアクセスをリクエストできます。 別の App では、コードへの読み取りおよび書き込みアクセスを持たせずに、Issue、ラベル、マイルストーンを管理させることが可能です。 OAuth appsでは詳しいアクセス許可は使えません。
| Access | アプリ (read または write アクセス許可) | OAuth apps |
|---|---|---|
| パブリック リポジトリへのアクセス | パブリックリポジトリはインストール中に選択する必要があります。 | public_repo スコープ。 |
| リポジトリ コード/コンテンツへのアクセス | リポジトリコンテンツ | repo スコープ。 |
| イシュー、ラベル、マイルストーンへのアクセス | 発行 | repo スコープ。 |
| pull request、ラベル、マイルストーンへのアクセス | Pull Request | repo スコープ。 |
| (CI ビルドの) コミットの状態へのアクセス | コミットのステータス | repo:status スコープ。 |
| デプロイおよびデプロイの状態へのアクセス | デプロイメント | repo_deployment スコープ。 |
| Webhook 経由によるイベントの受信 | App には、デフォルトで webhook が含まれています。 | write:repo_hook または write:org_hook スコープ。 |
リポジトリの確認
| アプリ | OAuth apps |
|---|---|
アプリでは /installation/repositories を参照して、インストール時にアクセスできるリポジトリを確認できます。 | OAuth apps では、アクセス可能なリポジトリの /user/repos (ユーザー ビューの場合) または/orgs/:org/repos (組織ビューの場合) を参照できます。 |
| App は、リポジトリがインストールから追加または削除されたときに webhook を受信します。 | OAuth appsでは、組織内に新しいリポジトリが作成されたときに通知用の組織 Webhook が作成されます。 |
Webhooks
| アプリ | OAuth apps |
|---|---|
| デフォルトでは、 App には webhook が 1 つあり、その webhook は、アクセス権のあるすべてのリポジトリにおいて、受信するよう設定されたイベントを受信します。 | OAuth appsは、イベントを受信する必要がある各リポジトリのリポジトリ Webhook を作成するため、Webhook スコープを要求します。 |
| App は、Organization メンバーの権限で、特定の Organization レベルのイベントを受信します。 | OAuth apps は、組織レベルのイベントを受信する必要がある各組織に対し、組織 Webhook を作成するため組織 Webhook スコープを要求します。 |
| Webhook は、 アプリがアンインストールされると自動的に無効になります。 | OAuth appのアクセス トークンが削除される場合、Webhook は自動的に無効にならず、それらを自動的にクリーンアップする方法はありません。 手動で行うようにユーザーに依頼する必要があります。 |
Git アクセス
| アプリ | OAuth apps |
|---|---|
| アプリはリポジトリの内容へのアクセス許可を要求し、インストール アクセス トークンを使用して、HTTP ベースの Git 経由で認証を行います。 詳細については、「 アプリのインストール アクセス トークンの生成」を参照してください | OAuth apps は、write:public_key スコープを要求し、API を介してデプロイ キーを作ります。 その後、そのキーを使用して Git コマンドを実行できます。 |
| トークンは、HTTP パスワードとして使用されます。 | トークンは、HTTP ユーザ名として使用されます。 |
マシンアカウントとボットアカウントの比較
マシン ユーザー アカウントは、 のユーザー システムを使用して自動システムを分離する OAuth ベースの個人用アカウントです。
ボットアカウントは App 固有のもので、すべての App に組み込まれています。
| アプリ | OAuth apps |
|---|---|
| App ボットは、 Enterprise シートを消費しません。 | マシン ユーザー アカウントは、 Enterprise シートを消費します。 |
| App ボットにはパスワードが付与されないため、顧客は App に直接サインインできません。 | マシンユーザアカウントには、ユーザ名およびパスワードが付与されます。顧客はそれらを管理および保護します。 |