OAuth app のアクセス制限について
OAuth app のアクセス制限が有効になっていると、Organization のメンバーと外部コラボレーターは、Organization のリソースへの OAuth app のアクセスを認可できません。 Organizationのメンバーは、使用したいOAuth appsの承認をオーナーにリクエストでき、Organizationオーナーは保留になっているリクエストの通知を受信します。
Organization の所有者は、外部コラボレーターが承認されていない OAuth apps と GitHub Apps へのアクセスを要求できるようにするかどうかを選べます。 詳しくは、「OAuth アプリと GitHub App のアクセス要求を制限する」を参照してください。
組織で OAuth apps のアクセスを制限した場合でも、ユーザーは内部 OAuth apps アプリを認可し、それらを使って組織のデータにアクセスできます。 詳しくは、「内部 OAuth アプリ」を参照してください。
新しい Organization を作成する際には、OAuth app アクセス制限が既定で有効です。 Organization 所有者はいつでもOAuth app アクセス制限を無効にできます。
Tip: 組織が OAuth app のアクセス制限を設定していない場合、組織のメンバーが認可したすべての OAuth app は、組織のプライベート リソースにもアクセスできます。
組織のリソースをさらに保護するために、SAML シングル サインオンのようなセキュリティ機能を備えた GitHub Enterprise Cloud にアップグレードすることができます。 GitHub Enterprise Cloud を無料で試す方法の詳細については、「GitHub Enterprise Cloud の試用版を設定する」を参照してください。
OAuth appのアクセス制限のセットアップ
OrganizationのオーナーがOAuth appのアクセス制限を初めてセットアップする場合、以下のようになります。
- 組織が所有するアプリケーションには、組織のリソースへのアクセスが自動的に付与されます。
- OAuth apps は、組織のリソースへのアクセスを即座に失います。
- 2014 年 2 月以前に作成された SSH キーは、組織のリソースへのアクセスを即座に失います (これにはユーザーおよびデプロイ キーが含まれます)。
- 2014 年 2 月中、あるいはそれ以降に OAuth apps によって作成された SSH キーは、組織のリソースへのアクセスを即座に失います。
- プライベートの組織リポジトリからのフックの配信は、承認されていない OAuth apps には送信されなくなります。
- 承認されていない OAuth apps でのプライベートな組織のリソースへの API アクセスはできなくなります。 加えて、パブリックなOrganizationリソースの作成、更新、削除のアクションの権限はありません。
- ユーザーが作成したフックおよび 2014 年 5 月より前に作成されたフックには影響ありません。
- 組織が所有するリポジトリのプライベート フォークは、組織のアクセス制限に従います。
SSHアクセスの失敗の解決
OAuth appのアクセス制限が有効化されたOrganizationへのアクセスを2014年2月以前に作成されたSSHキーが失った場合、それ以降のSSHアクセスの試行は失敗します。 ユーザには、キーを認可できる、あるいは信頼されたキーをそこにアップロードできるURLを示すエラーメッセージが返されます。
Webhooks
OAuth appが制限が有効化された後のOrganizationへのアクセスを許可された場合、そのOAuth appが作成した既存のwebhookは、ディスパッチを再開します。
Organizationが以前に認可されたOAuth appからアクセスを削除した場合、そのアプリケーションが作成した既存のwebhookはディスパッチされなくなります（それらのフックは無効化されますが、削除はされません）。
アクセス制限の再有効化
OrganizationがOAuth appのアクセスアプリケーション制限を無効化し、後に再び有効化した場合、以前に認可されていたOAuth appは自動的にOrganizationのリソースへのアクセスを許可されます。