パブリック クライアント アプリケーションと機密クライアント アプリケーション

Microsoft Authentication Library (MSAL) には、パブリック クライアントと機密クライアントの 2 種類のクライアントが定義されています。 クライアントは、ID プロバイダーによって割り当てられた一意識別子を持つソフトウェア エンティティです。 クライアントの種類は、承認サーバーで安全に認証する機能と、ID を提供する機密情報を保持して、アクセスのスコープ内でその情報がユーザーにアクセスされたり知られたりできないようにする機能によって区別されます。

パブリック クライアント アプリ	機密クライアント アプリ
デスクトップ アプリ	Web アプリ
ブラウザーレス API	Web API
モバイル アプリ	サービス/デーモン

パブリック クライアントと機密クライアントの認可

特定のクライアントの性質がパブリックであるか機密であるかを調べる場合、そのクライアントが認証サーバーに自身の ID を証明できるかどうかを評価します。 承認サーバーがアクセス トークンを発行するには、クライアントの ID を信頼できる必要があるため、これは重要です。

• パブリック クライアント アプリケーションはデスクトップなどのデバイス上で実行され、ブラウザーレス API、モバイル アプリ、クライアント側のブラウザー アプリなどがあります。 これらは、ユーザーに代わって Web API にアクセスできるだけであり、アプリケーション シークレットが安全に保持されるかどうかは信頼できません。 特定のアプリのソースまたはコンパイル済みバイトコードが、信頼されていないパーティによる読み取り、逆アセンブル、またはその他の方法での検査が可能な場所にいつでも送信される場合、それはパブリック クライアントです。 また、パブリック クライアントは、パブリック クライアント フローのみをサポートし、構成時のシークレットを保持できないため、クライアント シークレットを持つことはできません。

• 機密クライアント アプリケーションはサーバー上で実行され、Web アプリ、Web API アプリ、サービス/デーモン アプリなどがあります。 これらはユーザーや攻撃者によるアクセスが難しいと考えられており、そのため、構成時のシークレットを適切に保持して、その ID の証拠をアサートすることができます。 クライアント ID は Web ブラウザーを介して公開されますが、シークレットはバック チャネルでのみ渡され、直接公開されることはありません。

アプリの登録でパブリック クライアント フローを有効にする必要があるのはいつですか?

ビルドするクライアント アプリケーションの種類を決定すると、アプリの登録でパブリック クライアント フローを有効にするかどうかを決定できます。 既定では、ユーザーまたは開発者がパブリック クライアント アプリケーションをビルドし、次の OAuth 認可プロトコルまたは機能を使用していない限り、アプリの登録でパブリック クライアント フローを許可することを無効にする必要があります。

ID を証明する上でのシークレットとその重要性

以下に、クライアントが承認サーバーに対して自身の ID を証明する方法の例をいくつか示します。

• Azure リソースのマネージド ID - アプリのみの認証シナリオの場合、Azure 上に構築するアプリケーションおよびサービスの開発者には、シークレットの管理、ローテーション、保護をプラットフォーム自体にオフロードするオプションがあります。 マネージド ID を使用すると、ID は Azure リソースと共に提供および削除され、全体管理者を含め誰も、基になる資格情報にアクセスすることはできません。 マネージド ID を使用すると、機密漏洩のリスクを防ぎ、プロバイダーにセキュリティへの対処を任せることができます。
• クライアント ID とシークレット - このパターンでは、クライアントの登録時に承認サーバーによって値のペアが生成されます。 クライアント ID はアプリケーションを識別するパブリック値であり、クライアント シークレットはアプリケーションの ID を証明するために使用される機密値です。
• 証明書の所有の証明 - X.509 などの標準を含む公開キー基盤 (PKI) は、インターネット上での安全な通信を可能にし、インターネット プライバシーのバックボーンを形成する基本的なテクノロジです。 PKI は、オンライン通信に関与するパーティの ID を確認するデジタル証明書を発行するために使用され、Web トラフィックのセキュリティ保護に広く使用されている HTTPS などのプロトコルを強化するための基盤となるテクノロジです。 同様に、証明書を使用すると、サービス間の相互認証を有効にして、Azure でのサービス間 (S2S) 通信をセキュリティで保護できます。 このためには、各サービスがその ID を証明する手段として証明書を他のサービスに提示する必要があります。
• 署名付きアサーションの提示 - 署名付きアサーションをワークロード ID フェデレーションで使用すると、信頼されたサード パーティの ID プロバイダー トークンを Microsoft ID プラットフォームと交換して、Microsoft Entra で保護されたリソースを呼び出すためのアクセス トークンを取得できます。 ワークロード ID フェデレーションを使用すると、Azure Kubernetes Service、アマゾン ウェブ サービス EKS、GitHub Actions など、さまざまなフェデレーション シナリオを有効にすることができます。

クライアントの ID を証明することが重要な場合

機密データやリソースへのアクセスを許可する前に、クライアント アプリケーションの信頼性と承認の両方を検証する必要がある場合、クライアント ID を証明することが重要になります。 次に例をいくつか示します。

• API アクセスの制御 - 測定される (たとえば、従量制課金など) API がある場合、または機密データやリソースを公開する場合、アクセスを許可する前にクライアントの ID を確認します。 たとえば、これは、確実に承認されたアプリケーションのみが API にアクセスできるようにする場合、および従量制課金 API の使用に対して適切な顧客に確実に課金されるようにする場合に重要です。
• アプリの偽装からのユーザー保護 - サービスにデプロイされ、機密データやサービスにアクセスするユーザー向けアプリケーション (バックエンド駆動型 Web アプリなど) がある場合、クライアント シークレットを使用して、そのアプリケーションで使用されるリソースを保護すると、不正なアクターが正規のクライアントを偽装してユーザーをフィッシングしたり、データや不正アクセスを流出させたりするのを防ぐことができます。
• S2S 通信 - 相互に通信する必要がある複数のバックエンド サービス (ダウンストリーム API など) がある場合は、各サービスの ID を確認して、その機能を実行するために必要なリソースに対してのみアクセスが許可されていることを確認できます。

一般に、ユーザーとは関係なく、またはユーザーに加えて、クライアントを認証および承認する必要がある場合、クライアント ID を証明することが重要になります。

機密クライアント: シークレットを管理するためのベスト プラクティス

マネージド ID を使用してデプロイとセキュリティを簡略化する - マネージド ID を使用すると、Microsoft Entra 認証をサポートするリソースに接続するときにアプリケーションで使用される Microsoft Entra ID のマネージド ID が自動的に提供されます。 アプリケーションでは、マネージド ID を使用して Microsoft Entra ID アプリ専用トークンを取得でき、資格情報を管理する必要はありません。 これにより、セキュリティと回復性を高めながら、シークレット管理に伴う複雑さの多くを取り除くことができます。 マネージド ID を使用している場合は、次のベスト プラクティスのすべてではないとしてもほとんどが、既に対応されています。

セキュリティで保護されたストレージを使用する - Key Vault や暗号化された構成ファイルなど、セキュリティで保護された場所にクライアント シークレットを格納します。 クライアント シークレットをプレーンテキストで格納したり、バージョン管理システムにチェックイン済みファイルとして格納したりしないようにしてください。

アクセスを制限する - クライアント シークレットへのアクセスを、承認された担当者のみに制限します。 クライアント シークレットへのアクセスを、運用業務を履行するために必要とするユーザーのみに制限するには、ロールベースのアクセス制御を使用します。

クライアント シークレットをローテーションする - 必要に応じて、またはスケジュールに基づいてクライアント シークレットをローテーションすると、不正アクセスを取得するために侵害されたシークレットが使用されるリスクを最小限に抑えることができます。 適用する場合、提案されるキーの使用継続期間は、使用される暗号アルゴリズムの強度、または標準への準拠や規制コンプライアンス プラクティスによる影響を受けます。

長いシークレットと強力な暗号化を使用する - 前のポイントと密接に関連しますが、転送中 (ネットワーク上) と保存時 (ディスク上) の両方のデータに強力な暗号化アルゴリズムを使用すると、エントロピーの高いシークレットがブルート フォース攻撃を受ける可能性が確実に低くなります。 AES-128 (以上) などのアルゴリズムは保存データの保護に役立ち、RSA-2048 (以上) は転送中のデータの効率的な保護に役立ちます。 サイバーセキュリティは進化し続ける性質があるため、セキュリティの専門家に相談し、アルゴリズムの選択を定期的に見直すことが常にベスト プラクティスです。

シークレットのハードコーディングを回避する - クライアント シークレットをソース コードにハードコーディングしないでください。 シークレットをソース コードに含めないようにすると、不正なアクターがソース コードにアクセスする価値を最小限に抑えることができます。 また、このようなシークレットが、安全ではないリポジトリに誤ってプッシュされたり、ソースにアクセスできるがシークレットにはアクセスできないプロジェクトの共同作成者が使用できるようになったりするのを防ぐこともできます。

リポジトリでシークレットの漏えいを監視する - 残念ながら、ソース コードを扱うときに不正なチェックインが発生するのは事実です。 Git の事前コミット フックは、誤ったチェックインを防ぐための推奨される方法ですが、監視の代わりにもなる方法ではありません。 リポジトリの自動監視を使用すると、漏洩したシークレットを特定でき、侵害された資格情報をローテーションする計画があれば、セキュリティ インシデントの削減に役立ちます。

不審なアクティビティを監視する - クライアント シークレット関連の不審なアクティビティに関する Monitor ログと監査証跡。 可能な場合、自動化されたアラートと応答プロセスを使用して担当者に通知し、クライアント シークレットに関連する異常なアクティビティに対するコンティンジェンシーを定義します。

クライアントの秘密を念頭に置いてアプリケーションを設計する - セキュリティ モデルの強度は、チェーン内の最も弱いリンクと同じくらいです。 クライアント シークレット データがパブリック クライアントに移動されると、機密クライアントの偽装が可能になるおそれがあるため、セキュリティ資格情報またはセキュリティ トークンを機密クライアントからパブリック クライアントに転送しないでください。

信頼できるソースの最新のライブラリと SDK を使用する - Microsoft ID プラットフォームは、アプリケーションの安全性を維持しながら生産性を向上するように設計されたさまざまなクライアント SDK、サーバー SDK、ミドルウェアを提供します。 Microsoft.Identity.Web を使用すると、Microsoft ID プラットフォーム上の Web アプリと API に対する認証と承認の追加が簡略化されます。 依存関係を常に最新の状態に保つと、アプリケーションとサービスがセキュリティに関する最新のイノベーションと更新の恩恵を受けることができます。

クライアントの種類と機能の比較

パブリック クライアント アプリと機密クライアント アプリの共通点および相違点をいくつか以下に示します。

• どちらの種類のアプリもユーザー トークン キャッシュを保持し、トークンをサイレントに取得できます (トークンがキャッシュに存在する場合)。 機密クライアント アプリには、アプリ自体によって取得されたトークン用のアプリ トークン キャッシュもあります。
• どちらの種類のアプリでも、ユーザー アカウントの管理、ユーザー トークン キャッシュからのアカウントの取得、識別子からのアカウントの取得、またはアカウントの削除を行うことができます。
• MSAL では、パグリック クライアント アプリには、個別の認証フローを通じてトークンを取得するための 4 つの方法があります。 機密クライアント アプリには、トークンを取得する方法は 3 つのみで、ID プロバイダーの承認エンドポイントの URL を計算するための方法が 1 つあります。 "クライアント ID" は、アプリケーションの構築時に 1 回渡され、アプリでトークンを取得するときに再度渡す必要はありません。 詳細については、トークンの取得に関するページを参照してください。

パブリック クライアントは、保護されたリソースへのユーザー委任アクセスを有効にするのに役立ちますが、独自のアプリケーション ID を証明することはできません。 一方、機密クライアントはユーザーとアプリケーションの両方の認証と承認を実行でき、シークレットがパブリック クライアントや他のサード パーティと共有されないようにセキュリティを念頭に置いてビルドする必要があります。

S2S 通信などの場合、マネージド ID などのインフラストラクチャは、サービスの開発とデプロイを簡略化し、シークレット管理に通常伴う複雑さの多くを取り除くのに大いに役立ちます。 マネージド ID を使用できない場合は、シークレットをセキュリティで保護し、シークレット関連のセキュリティ インシデントに対応するためのポリシー、予防措置、コンティンジェンシーを設定することが重要です。

関連項目

アプリケーションの構成とインスタンス化の詳細については、以下を参照してください。

• クライアント アプリケーション構成オプション
• MSAL.NET を使用したクライアント アプリケーションのインスタンス化
• MSAL.js を使用したクライアント アプリケーションのインスタンス化