フェデレーション ID パターン

開発を簡素化し、管理タスクを最小限に抑え、アプリケーション UX を向上させるために、ユーザー認証を外部 ID プロバイダー (IdP) に委任します。

コンテキストと問題

通常、ユーザーはパートナー組織が提供およびホストする複数のアプリケーションを操作する必要があります。アプリケーションごとに特定の異なるサインイン資格情報を使用する必要がある場合があります。この要件では、次のことができます。

不整合な UX を発生させる。 従業員は、多くの場合、複数のサインイン資格情報を忘れています。
セキュリティの脆弱性を公開します。 従業員が退職した場合、組織は直ちにアカウントを非アクティブ化する必要があります。大規模な組織は、多くの場合、この重要な手順を見逃します。
ユーザー管理を複雑にします。 管理者は、ユーザーの資格情報の管理、パスワードアラームの発行、その他の管理タスクの実行を行います。

ユーザーは通常、すべてのアプリケーションで同じサインイン資格情報を使用することを好みます。

ソリューション

フェデレーション ID 認証メカニズムを実装します。アプリケーションコードからユーザー認証を分離し、認証を信頼された IdP に委任します。このプロセスにより、開発が簡素化され、管理オーバーヘッドが最小限に抑えられます。また、さまざまな IdP を介してユーザー認証が提供されます。フェデレーション ID では、認証と承認も分離されます。

信頼できる IdP には、企業ディレクトリ、オンプレミスのフェデレーションサービス、セキュリティトークンサービス (STS)、ソーシャル IdP (Microsoft、Google、Yahoo!、Facebook など) が含まれます。

次の図は、認証を必要とするサービスにアクセスするクライアントアプリケーションのフェデレーション ID パターンを示しています。 IdP は STS と連携して認証を提供します。 IdP は、認証されたユーザーの情報を提供するセキュリティトークンを発行します。要求と呼ばれるこの情報には、ユーザーの ID が含まれており、ロールメンバーシップやより詳細なアクセス権など、他の要求も含まれる場合があります。

このモデルは、クレームベースのアクセス制御とも呼ばれます。アプリケーションとサービスは、要求に基づいて機能へのアクセスを承認します。認証が必要なサービスは、IdP を信頼する必要があります。クライアントアプリケーションは、認証のために IdP に接続します。認証が成功した場合、IdP は STS に対するユーザー識別クレームを含むトークンを返します。 IdP と STS は、同じサービスの一部である可能性があります。 STS は、トークンをクライアントに返す前に、定義済みの規則に基づいて要求を変換および拡張できます。その後、クライアントアプリケーションは、ID の証明としてこのトークンをサービスに渡します。

フェデレーション認証は、ドメイン間の ID で信頼を確立するための標準ベースの方法を提供し、シングルサインオン (SSO) をサポートします。多くのアプリケーション (特にクラウドでホストされるアプリケーション) では、IdP への直接ネットワーク接続なしで SSO がサポートされるため、フェデレーション認証が使用されます。この設計により、ユーザーは複数のアプリケーションに対して異なるサインイン資格情報を作成して入力する必要がないため、セキュリティが向上します。また、資格情報の公開は元の IdP のみに制限されます。アプリケーションでは、トークン内の認証済み ID 情報のみが表示されます。

フェデレーション認証を使用するアプリケーションとサービスでは、ID 管理機能を提供する必要はありません。代わりに、IdP は ID と資格情報の管理を担当します。企業ディレクトリが IdP を信頼する場合、ユーザー ID を管理する必要はありません。この方法により、ディレクトリベースのユーザー ID 管理の管理オーバーヘッドが解消されます。

問題と考慮事項

このパターンの実装方法を決めるときには、以下の点に注意してください。

認証は単一障害点になる可能性があります。複数のリージョンにわたってアプリケーションの信頼性と可用性を維持するには、アプリケーションと同じリージョンに ID 管理メカニズムをデプロイすることを検討してください。
ロールベースのアクセス制御 (RBAC) を構成するには、認証ツールを使用します。 RBAC では、機能とリソースアクセスをきめ細かく制御できます。
企業ディレクトリとは異なり、ソーシャル IdP を使用するクレームベースの認証では、通常、認証されたユーザーの電子メールアドレスと、場合によってはその名前のみが提供されます。 Microsoftなどの一部のソーシャル IDP では、一意の識別子のみが提供されます。アプリケーションは通常、登録されたユーザーに関する情報を保持するため、この情報をクレーム内の識別子と照合できます。通常、このタスクは、ユーザーがアプリケーションに初めてアクセスするときに、登録中に完了します。その後、各認証の後に、情報が新しい要求としてトークンに挿入されます。
STS に対して複数の IdP が構成されている場合、STS はユーザーを認証する IdP を決定する必要があります。このプロセスは、 ホーム領域検出と呼ばれます。 STS は、電子メールアドレスやユーザー名、アプリケーションサブドメイン、ユーザーの IP アドレス範囲、ユーザーのブラウザーに格納されている Cookie など、ユーザーが指定した情報に基づいて IdP を自動的に決定する場合があります。たとえば、ユーザーがuser@live.comなどのMicrosoftメールアドレスを入力すると、STS はユーザーを Microsoft アカウントサインインページにリダイレクトします。その後のアクセス時に、STS は、ユーザーが以前にMicrosoft アカウントを使用してサインインしたことを示す Cookie を使用できます。 STS がホーム領域を自動的に決定できない場合は、信頼された IdP を一覧表示するホーム領域検出ページが表示されます。その後、ユーザーは IdP を選択します。

このパターンを使用する場合

必要な場合は、次のパターンを使用します。

エンタープライズでの SSO。 このシナリオでは、アプリケーションにアクセスするたびにサインインすることなく、企業のセキュリティ境界外のクラウドでホストされている企業アプリケーションの従業員を認証する必要があります。ユーザーエクスペリエンスは、オンプレミスのアプリケーションと一致します。ユーザーは、企業ネットワークにサインインするときに認証を行い、別のサインインなしで関連するアプリケーションにアクセスできます。
複数のパートナーとのフェデレーション ID。 このシナリオでは、企業ディレクトリにアカウントを持たない会社の従業員とビジネスパートナーを認証する必要があります。この方法は、企業間アプリケーション、パートナーサービスと統合するアプリケーション、および異なる IT システムを使用する企業、またはマージまたは共有リソースで一般的です。
サービスとしてのソフトウェア (SaaS) アプリケーションのフェデレーション ID。 このシナリオでは、独立系ソフトウェアベンダーは、複数のクライアントまたはテナントに対してすぐに使用できるサービスを提供します。テナントは、適切な IdP を使用して認証します。たとえば、ビジネスユーザーは会社の資格情報を使用し、テナントのコンシューマーとクライアントはソーシャル ID 資格情報を使用します。
ワークロードアクセスのフェデレーション ID。 このシナリオでは、テナントアプリケーション、自動化ワークフロー、または継続的インテグレーションおよび継続的デリバリーシステムは、ユーザーなしで API を呼び出す必要があります。テナントは、ワークロード ID を使用して、各自の IdP 経由で認証します。アプリケーションは、テナントスコープの要求検証を使用してアクセスを承認します。

このパターンは、次の場合には適さない場合があります。

1 つの IdP。 このシナリオでは、アプリケーションユーザーは 1 つの IdP を使用して認証します。別の IdP を使用して認証する必要はありません。この状況は、認証に企業ディレクトリを使用するアプリケーションで一般的に、アプリケーションとオンプレミスディレクトリの間の VPN または仮想ネットワーク接続を使用します。
互換性のない認証メカニズム。 このシナリオでは、アプリケーションは、カスタムユーザーストアを使用するなど、別の認証メカニズムを使用するか、クレームベースのテクノロジネゴシエーション標準を処理できません。クレームベースの認証とアクセス制御を既存のアプリケーションに換装するのは、複雑でコストがかかる場合があります。

ワークロード設計

ワークロードの設計でフェデレーション ID パターンを使用して、Azure Well-Architected Framework の柱で説明されている目標と原則に対処する方法を評価します。次の表は、このパターンが各柱の目標をサポートする方法に関するガイダンスを示しています。

柱	このパターンが柱の目標をサポートする方法
信頼性設計の決定は、故障に対するワークロードの回復性を高め、障害の発生後にワークロードを完全な機能状態に回復させるために役立ちます。	このパターンは、ユーザー管理と認証を IdP にオフロードします。IdP は、通常、高いサービスレベルの目標を持ちます。ワークロードディザスターリカバリー (DR) 中に、ワークロード回復計画で認証コンポーネントに対処する必要はありません。 - RE:02 重要な流れ - RE:09 DR
セキュリティ設計の決定により、ワークロードのデータとシステムの機密性、整合性、および可用性が確保されます。	このパターンにより、高度な ID ベースの脅威検出と防止機能が提供されます。ワークロードに実装する必要はありません。外部 IdP は、最新の相互運用可能な認証プロトコルも使用します。 - SE:02 セキュアな開発ライフサイクル - SE:10 監視と脅威の検出
パフォーマンス効率は、スケーリング、データ、およびコードの最適化を通じて、ワークロードの需要を効率的に満たすのに役立ちます。	このパターンは、他の優先順位にアプリケーションリソースを割り当てるのに役立ちます。 - PE:03 サービスの選択

このパターンによって柱内にトレードオフが生じる場合は、他の柱の目標に照らして検討してください。

Example

組織は、Web フロントエンドとバックエンド API を含むマルチコンポーネントクラウドベースのアプリケーションをホストします。アプリケーションは、各コンポーネントに認証ロジックを実装するのではなく、Microsoft Entra IDを使用して一元化された IdP に認証を委任します。

このアーキテクチャのVisio ファイルをダウンロードしてください。

次のワークフローは、前の図に対応しています。

ユーザーが Web アプリにアクセスします。
Web アプリは、認証のためにユーザーをMicrosoft Entra IDにリダイレクトします。
認証が成功すると、Microsoft Entra IDは承認コードを使用してユーザーを Web アプリにリダイレクトします。
Web アプリは、トークンの承認コードを交換し、トークンエンドポイントに POST 要求を送信します。
Microsoft Entra IDは、ユーザーに関する要求を含むトークンを発行します。
Web アプリは、このトークンを使用してバックエンド API を呼び出します。
Web アプリとバックエンド API はトークンを検証し、要求に基づいて承認規則を適用します。
API は Web アプリに応答を返します。

主な特性:

一元化された認証。 コンポーネントはMicrosoft Entra IDに依存してユーザーを認証するため、アプリケーションでカスタム認証ロジックが不要になります。
分散型承認。 アプリケーションコンポーネントは、要求に基づいて承認の決定を個別に適用します。
クレームベースのアクセス制御。 機能へのアクセスは、ロールやスコープなどの要求を使用して決定されます。
標準ベースのプロトコル。 コンポーネントでは、認証に OAuth 2.0 と OpenID Connect が使用されます。
オプションの MFA の適用。 リスクプロファイルでサインイン保証の強化が必要な場合は、Microsoft Entra IDの条件付きアクセスポリシーを使用して多要素認証を適用できます。
フェデレーションによるオプションの拡張。 Microsoft Entra IDは、テナント間アクセス設定を使用して、パートナー Microsoft Entraテナントを信頼するように構成できます。パートナーユーザーは、アプリケーションコンポーネントに変更を加えることなく、アプリケーションにアクセスできます。

次のステップ

マルチテナントソリューションでの ID のアーキテクチャに関する考慮事項
ゲートキーパーパターン
バレットキーパターン
Gateway Offloading pattern (ゲートウェイオフロードパターン)

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-07-02