OAuth アプリを作成するためのベストプラクティス

代わりに GitHub App を使用する

可能な場合、OAuth app の代わりに GitHub App を使用することを検討してください。通常、GitHub Apps が OAuth apps より優先されます。 GitHub Apps では、きめ細かいアクセス許可が使われ、アプリでアクセスできるリポジトリをより細かく制御でき、有効期間の短いトークンが使われます。これらの特徴により、アプリの資格情報が漏洩した場合に発生するおそれがある損害を制限することで、アプリのセキュリティを強化できます。

OAuth apps と同様に、GitHub Apps でも引き続き OAuth 2.0 を使って、OAuth トークンの種類 (別名、ユーザーアクセストークン) を生成し、ユーザーに代わってアクションを実行できます。ただし、GitHub Apps は、ユーザーとは関係なく動作することもできます。

GitHub Apps について詳しくは、「GitHub App の作成について」をご覧ください。

既存の OAuth app の GitHub App への移行について詳しくは、「OAuth アプリからGitHub Appへの移行」をご覧ください。

最小限のスコープを使用する

OAuth app は、アプリが意図されている機能を実行するために必要なスコープのみを要求する必要があります。アプリのトークンが侵害された場合、これにより発生するおそれのある損害の量を制限できます。詳しくは、「OAuth アプリの承認」を参照してください。

徹底的かつ永続的な承認

ユーザーにサインインした後、アプリ開発者は追加の手順を実行して、ユーザーがシステム内のデータにアクセスできるようにする必要があります。各サインインには、メンバーシップ、アクセス、現在の SSO 状態に関する新しいチェックが必要です。

永続的で一意の `id` を使用してユーザーを格納する

ユーザーがサインインしてアプリケーションでアクションを実行するときは、次回サインインしたときに同じリソースへのアクセス権を付与するために、どのユーザーがそのアクションを実行したかを覚えておく必要があります。

ユーザーをデータベースに正しく格納するには、常にユーザーの id を使用します。この値は、ユーザーに対して変更されることも、別のユーザーを指し示すために使用されることもないため、意図したユーザーへのアクセスを確実に提供できます。ユーザーの id を GET /user REST API エンドポイントで確認できます。「ユーザーの REST API エンドポイント」をご覧ください。

リポジトリ、組織、および企業へのリファレンスを格納する場合は、それらの id を使用して、リンクが正確であることを確認します。

ユーザーハンドル、組織の置換フィールド、メールアドレスなど、時間の経過に伴い変化する可能性のある識別子を 絶対に 使用しないでください。

新しい認証ごとに組織へのアクセスを検証する

ユーザーアクセストークンを使用する場合は、トークンが承認されている組織を追跡する必要があります。組織が SAML SSO を使用していて、ユーザーが SAML SSO を実行していない場合、ユーザーアクセストークンはその組織にアクセスできません。 REST API エンドポイントを GET /user/installations 使用して、ユーザーアクセストークンがアクセスできる組織を確認できます。ユーザーが組織へのアクセスを許可されていない場合は、SAML SSO を実行するまで、独自のアプリケーション内の組織所有データへのアクセスを防止する必要があります。詳しくは、「GitHub Appインストール用 REST API エンドポイント」を参照してください。

organization コンテキストと Enterprise コンテキストを使用してユーザーデータを格納する

id フィールドを使用してユーザー ID を追跡するだけでなく、各ユーザーが操作している組織または企業のデータを保持する必要があります。これにより、ユーザーがロールを切り替えた場合に、機密情報が漏えいしないようにすることができます。

次に例を示します。

ユーザーは、SAML SSO を必要とする Mona 組織にいて、SSO の実行後にアプリにサインインします。これで、アプリはユーザーが Mona 内で行うあらゆるものにアクセスできるようになりました。
ユーザーは、Mona 内のリポジトリから多数のコードを抜き取り、分析するためにアプリに保存します。
その後、ユーザーはジョブを切り替え、Mona 組織から削除されます。

ユーザーがアプリにアクセスしても、ユーザーアカウントに Mona 組織のコードと分析をまだ表示できますか?

このため、アプリが保存しているデータのソースを追跡することが重要です。それ以外の場合、アプリは組織のデータ保護にとって脅威であり、アプリがデータを正しく保護しているか信頼できない場合は、そのアプリを禁止する可能性があります。

アプリへのユーザーアクセスを検証する

OAuth アプリには、組織外または企業外のユーザーがアクセスできます。組織または企業のメンバーのみがアプリを使用できるようにする場合は、ユーザーがアプリにサインインするときにユーザーのメンバーシップの状態をチェックする必要があります。

ユーザーがメンバーになっている組織の一覧を見つけるには、「認証済みユーザーの組織を一覧表示する」エンドポイントを使用できます。その後、アプリに対して承認された組織の一覧に対してこの一覧を検証できます。詳しくは、「Organization の REST API エンドポイント」を参照してください。

アプリの資格情報をセキュリティで保護する

クライアントシークレットを使用すると、アプリでユーザーを承認し、ユーザーアクセストークンを生成できます。これらのトークンを使用すると、ユーザーに代わって API 要求を行うことができます。

アプリのクライアントシークレットと生成されたトークンを安全に格納する必要があります。保存方法は、統合アーキテクチャと稼働するプラットフォームによって異なります。一般に、使用中のプラットフォームに機密データを保存することを目的とした保存方法を使用する必要があります。

クライアントシークレット

アプリが Web サイトまたは Web アプリの場合は、Azure Key Vault などのキーコンテナーにクライアントシークレットを保存するか、暗号化された環境変数またはサーバー上のシークレットとして保存することを検討してください。

アプリがネイティブクライアントやクライアント側アプリの場合、またはユーザーデバイスで稼働している (サーバー上で稼働しているのではなく) 場合は、クライアントシークレットをセキュリティ保護することはできません。誰でもクライアントシークレットにアクセスしてトークンを生成できるため、アプリが生成するトークンに基づいて独自のサービスへのアクセスを制御する場合は注意が必要です。

ユーザーアクセストークン

アプリが Web サイトや Web アプリの場合は、バックエンドでトークンを暗号化し、トークンにアクセスできるシステムのセキュリティを確保する必要があります。アクティブなアクセストークンとは別の場所に更新トークンを保存することを検討してください。

アプリがネイティブクライアントやクライアント側アプリの場合、またはユーザーデバイスで稼働している (サーバー上で稼働しているのではなく) 場合は、トークンとサーバー上で稼働するアプリをセキュリティ保護できないことがあります。アプリのプラットフォームに推奨される方法を使用してトークンを保存する必要があり、保存方法が完全に安全ではないことがあることに注意してください。