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