英語で読む

次の方法で共有

Active Directory B2C で使用できるアプリケーションの種類

  • [アーティクル]

Azure Active Directory B2C (Azure AD B2C) では、さまざまな最新アプリケーション アーキテクチャの認証がサポートされています。 すべての認証は、業界標準のプロトコルである OAuth 2.0 または OpenID Connect に基づいています。 この記事では、選択する言語またはプラットフォームには関係なく、構築できるアプリケーションの種類について説明します。 また、アプリケーションの構築を始める前にシナリオの概要を理解することもできます。

Azure AD B2C を使用しているすべてのアプリケーションは、Azure portal を使用して Azure AD B2C テナントに登録する必要があります。 アプリケーション登録プロセスでは、次のような値が収集されて割り当てられます。

  • アプリケーションを一意に識別する アプリケーション ID。
  • 応答をアプリケーションにリダイレクトして戻すために使用できる応答 URL。

Azure AD B2C に送信される各要求では、Azure AD B2C の動作を制御するユーザー フロー (組み込みのポリシー) またはカスタム ポリシーが指定されます。 どちらのポリシーの種類でも、高度にカスタマイズ可能な一連のユーザー エクスペリエンスを作成できます。

すべてのアプリケーションによるやり取りは、次のような大まかなパターンに従って行われます。

  1. アプリケーションは、ポリシーを実行するためにユーザーを v2.0 エンドポイントにリダイレクトします。
  2. ユーザーがポリシーの定義に従ってポリシーを完了します。
  3. アプリケーションが v2.0 エンドポイントからセキュリティ トークンを受け取ります。
  4. アプリケーションは、セキュリティ トークンを使って、保護された情報またはリソースにアクセスします。
  5. リソース サーバーは、セキュリティ トークンを検証し、アクセスを許可できることを確認します。
  6. アプリケーションは、セキュリティ トークンを定期的に更新します。

これらの手順は、構築しているアプリケーションの種類によりわずかに異なることがあります。

Web アプリケーション

Web サーバーでホストされ、ブラウザーを通じてアクセスされる Web アプリケーション (.NET、PHP、Java、Ruby、Python、Node.js など) に対して、Azure AD B2C は、すべてのユーザー エクスペリエンスで OpenID Connect をサポートします。 Azure AD B2C で OpenID Connect を実装する場合、Web アプリケーションでは、Microsoft Entra ID に認証要求が発行されて、ユーザー エクスペリエンスが開始します。 要求の結果は id_tokenです。 このセキュリティ トークンは、ユーザーの ID を表します。 また、要求の形式でユーザーに関する情報も提供します。

// Partial raw id_token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded id_token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "d9674823-dffc-4e3f-a6eb-62fe4bd48a58"
    ...
}

アプリケーションで利用できるトークンと要求の種類の詳細については、Azure AD B2C トークン リファレンスのページを参照してください。

Web アプリケーションでは、ポリシーを実行するたびに、次に示す大まかな手順が実行されます。

  1. ユーザーが Web アプリケーションに移動する。
  2. Web アプリケーションが実行するポリシーを示す Azure AD B2C にユーザーをリダイレクトする。
  3. ユーザーがポリシーを完了する。
  4. Azure AD B2C が id_token をブラウザーに返す。
  5. id_token がリダイレクト URI にポストされる。
  6. id_token が検証され、セッション cookie が設定される。
  7. セキュリティで保護されたページがユーザーに返される。

ユーザーの ID を確認するには、Microsoft Entra ID から受け取った公開署名キーを使って id_token を検証するだけで十分です。 このプロセスにより、以降のページ要求でユーザーを識別するために使用できるセッション Cookie も設定されます。

このシナリオを実際に確認するには、作業開始に関するセクションのいずれかの Web アプリケーション サインイン コード サンプルを試してください。

Web アプリケーションは、サインインをシンプルにするだけでなく、バックエンド Web サービスにアクセスすることが必要な場合もあります。 このような場合、Web アプリケーションでは少し異なる OpenID Connect フロー を実行し、承認コードと更新トークンを使用してトークンを取得することができます。 このシナリオについては、次の「 Web API」セクションで説明します。

シングルページ アプリケーション

多くの最新の Web アプリケーションは、クライアント側のシングル ページ アプリケーション ("SPA") として構築されています。 開発者は、JavaScript または SPA フレームワーク (Angular、Vue、React など) を使用してそれらを作成します。 これらのアプリケーションは Web ブラウザーで実行され、その認証には、従来のサーバー側 Web アプリケーションとは異なる特性があります。

Azure AD B2C により、シングルページ アプリケーションでユーザーをサインインさせ、バックエンド サービスまたは Web API にアクセスするためのトークンを取得する 2 つのオプションが提供されます。

認可コード フロー (PKCE あり)

OAuth 2.0 認可コード フロー (PKCE あり) では、認証されたユーザーを表す ID トークンと保護されている API を呼び出すために必要なアクセス トークンの認可コードを交換することをアプリケーションに許可します。 また、ユーザーが操作しなくてもユーザーの代わりにリソースへの長期間アクセスを提供する更新トークンが返されます。

Microsoft ではこのアプローチを推奨しています。 有効期間が制限された更新トークンを使用すると、Safari ITP のような最新のブラウザーの Cookie プライバシー制限にアプリケーションを適合させることができます。

このフローを活用するために、アプリケーションで、これをサポートする認証ライブラリ (MSAL.js 2.x など) を使用できます。

シングルページ アプリケーション認証

暗黙的な許可のフロー

MSAL.js 1.x のような一部のライブラリでは、暗黙的な許可フローのみをサポートするか、暗黙的なフローを使用するためにアプリケーションが実装されます。 これらの場合、Azure AD B2C によって OAuth 2.0 の暗黙的なフローがサポートされます。 暗黙的な許可フローでは、ID とアクセス トークンを取得することがアプリケーションに許可されます。 認可コード フローとは異なり、暗黙的な許可フローから更新トークンが返されることはありません。

このアプローチは推奨されません。

この認証フローには、Electron や React-Native などのクロスプラットフォーム JavaScript フレームワークを使用するアプリケーション シナリオは含まれません。 それらのシナリオでは、ネイティブ プラットフォームと対話するための追加の機能が必要になります。

Web API

Azure AD B2C を使用して、アプリケーションの RESTful Web API などの Web サービスをセキュリティで保護できます。 Web API では、OAuth 2.0 を使用し、トークンによって受信 HTTP 要求を認証することで、データをセキュリティで保護することができます。 Web API の呼び出し元は、HTTP 要求の承認ヘッダーの中にトークンを追加します。

GET /api/items HTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6...
Accept: application/json
...

Web API はトークンを使用して API の呼び出し元の ID を検証し、トークン内にエンコードされているクレームから呼び出し元に関する情報を抽出します。 アプリで利用できるトークンと要求の種類の詳細については、 Azure AD B2C トークン リファレンスのページを参照してください。

Web API は、Web アプリケーション、デスクトップ アプリケーション、モバイル アプリケーション、シングル ページ アプリケーション、サーバー サイド デーモン、それ以外の Web API など、多くの種類のクライアントからトークンを受信できます。 ここでは、Web API を呼び出す Web アプリケーションの完全なフローの例を示します。

  1. Web アプリケーションがポリシーを実行し、ユーザーがユーザー エクスペリエンスを完了する。
  2. Azure AD B2C が (OpenID Connect) id_token と承認コードをブラウザーに返す。
  3. ブラウザーが id_token と承認コードをリダイレクト URI にポストする。
  4. Web サーバーが id_token を検証し、セッション cookie を設定する。
  5. Web サーバーが、認可コード、アプリケーション クライアント ID、クライアントの資格情報を提供することで、Azure AD B2C に access_token を要求する。
  6. access_token と refresh_token が Web サーバーに返される。
  7. Authorization ヘッダーに access_token が含まれる Web API が呼び出される。
  8. Web API がトークンを検証する。
  9. セキュリティで保護されたデータが Web アプリケーションに返される。

承認コード、更新トークン、およびトークンの取得手順については、 OAuth 2.0 プロトコルに関するページを参照してください。

Azure AD B2C を使用して Web API をセキュリティ保護する方法の詳細については、Web API チュートリアルの「 作業開始」セクションを参照してください。

モバイルおよびネイティブ アプリケーション

モバイル アプリケーションやデスクトップ アプリケーションなどのデバイスにインストールされているアプリケーションは、多くの場合、ユーザーの代わりにバックエンド サービスや Web API にアクセスする必要があります。 カスタマイズされた ID 管理エクスペリエンスをネイティブ アプリケーションに追加し、Azure AD B2C と OAuth 2.0 の承認コード フローを使用して、バックエンド サービスを安全に呼び出すことができます。

このフローで、アプリケーションでは、ポリシーが実行され、ユーザーがポリシーを完了した後に Microsoft Entra ID から authorization_code を受け取ります。 authorization_code は、現在サインインしているユーザーに代わってバックエンド サービスを呼び出すためのアプリケーションのアクセス許可を表します。 これにより、アプリケーションはバックグラウンドで authorization_code を access_token および refresh_token と交換できます。 アプリケーションは access_token を使用し、HTTP 要求でバックエンド Web API への認証を行うことができます。 また、古い access_token の有効期限が切れたときは、refresh_token を使用して新しいものを取得できます。

デーモン/サーバー側アプリケーション

長時間実行されるプロセスを含んだアプリケーションや、ユーザーの介入なしで動作するアプリケーションも、セキュリティで保護されたリソース (Web API など) にアクセスする必要があります。 これらのアプリケーションは、(ユーザーの委任 ID ではなく) その ID を使用し、OAuth 2.0 クライアント資格情報フローを使用することで、認証を行い、トークンを取得することができます。 クライアント資格情報フローは、On-Behalf-Of フローと同じではなく、On-Behalf-Of フローは、サーバー対サーバー認証には使用しないようにする必要があります。

Azure AD B2C の場合、OAuth 2.0 クライアント資格情報フローは、現在パブリック プレビュー段階です。 ただし、Microsoft Graph アプリケーションまたは独自のアプリケーションでは、Microsoft Entra ID と Microsoft ID プラットフォーム /token エンドポイント (https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token) を使って、クライアント資格情報フローを設定することができます。 詳細については、Microsoft Entra のトークン リファレンスに関する記事を参照してください。

サポートされていないアプリケーションの種類

Web API チェーン (On-Behalf-Of フロー)

多くのアーキテクチャには別のダウンストリーム Web API を呼び出す必要がある Web API が含まれ、その場合は両方とも Azure AD B2C によってセキュリティ保護されます。 このシナリオは、バックエンドの Web API から Microsoft オンライン サービス (Microsoft Graph API など) を呼び出すネイティブ クライアントでよく見られます。

このように Web API を連鎖的に呼び出すシナリオは、OAuth 2.0 JWT Bearer Credential Grant (On-Behalf-Of フロー) を使用してサポートできます。 しかし、現時点では、Azure AD B2C に On-Behalf-Of フローは実装されていません。

次のステップ

「Azure Active Directory B2C のユーザー フロー」によって提供される組み込みのポリシーの詳細について学習します。