OAuth Appのアクセス制限が有効化されると、OrganizationのメンバーはOAuth AppのOrganizationのリソースへのアクセスを認可できなくなります。 Organizationのメンバーは、オーナーに対して使用したいOAuth Appの認可をリクエストでき、Organizationのオーナーはペンディングになっているリクエストの通知を受信します。
When you create a new organization, OAuth App access restrictions are enabled by default. Organizationのオーナーは、いつでもOAuth Appアクセス制限を無効化できます。
Tip：OrganizationがOAuth Appのアクセス制限をセットアップしていない場合、Organizationのメンバーが認可したすべてのOAuth Appは、Organizationのプライベートリソースにアクセスできます。
OAuth Appのアクセス制限のセットアップ
OrganizationのオーナーがOAuth Appのアクセス制限を初めてセットアップする場合、以下のようになります。
- Organizationが所有するアプリケーションには、自動的にOrganizationのリソースへのアクセスが与えられます。
- OAuth Appは、Organizationのリソースへのアクセスを即座に失います。
- 2014年の2月以前に作成されたSSHキーは、Organizationのリソースへのアクセスを即座に失います（これにはユーザ及びデプロイキーが含まれます）。
- OAuth Appによって2014年の2月あるいはそれ以降に作成されたSSHキーは、Organizationのリソースへのアクセスを即座に失います。
- プライベートのOrganizationリポジトリからのフックの配信は、認可されていないOAuth Appには送信されなくなります。
- 認可されていないOAuth AppからのプライベートなOrganizationのリソースへのAPIアクセスはできなくなります。 加えて、パブリックなOrganizationリソースの作成、更新、削除のアクションの権限はありません。
- ユーザが作成したフック及び2014年の5月以前に作成されたフックには影響ありません。
- Organizationが所有するリポジトリのプライベートフォークは、Organizationのアクセス制限に従います。
SSHアクセスの失敗の解決
OAuth Appのアクセス制限が有効化されたOrganizationへのアクセスを2014年2月以前に作成されたSSHキーが失った場合、それ以降のSSHアクセスの試行は失敗します。 ユーザには、キーを認可できる、あるいは信頼されたキーをそこにアップロードできるURLを示すエラーメッセージが返されます。
webhook
OAuth Appが制限が有効化された後のOrganizationへのアクセスを許可された場合、そのOAuth Appが作成した既存のwebhookは、ディスパッチを再開します。
Organizationが以前に認可されたOAuth Appからアクセスを削除した場合、そのアプリケーションが作成した既存のwebhookはディスパッチされなくなります（それらのフックは無効化されますが、削除はされません）。
アクセス制限の再有効化
OrganizationがOAuth Appのアクセスアプリケーション制限を無効化し、後に再び有効化した場合、以前に認可されていたOAuth Appは自動的にOrganizationのリソースへのアクセスを許可されます。