次の方法で共有

Azure Active Directory B2C のトークンの概要

  • [アーティクル]

重要

2025 年 5 月 1 日より、Azure AD B2C は新規のお客様向けに購入できなくなります。 詳細については、FAQ を参照してください。

Azure Active Directory B2C (Azure AD B2C) は、各 認証フローを処理するさまざまな種類のセキュリティ トークンを出力します。 この記事では、各種類のトークンの形式、セキュリティ特性、および内容について説明します。

トークンの種類

Azure AD B2C では OAuth 2.0 プロトコルと OpenID Connect プロトコルがサポートされています。このプロトコルでは、認証にトークンを使用し、リソースへのアクセスをセキュリティで保護します。 Azure AD B2C で使用されるすべてのトークンは、ベアラーとトークンのサブジェクトに関する情報のアサーションを含む JSON Web トークン (JWT) です。

Azure AD B2C との通信には、次のトークンが使用されます。

  • ID トークン - アプリケーション内のユーザーを識別するために使用できるクレームを含む JWT。 このトークンは、同じアプリケーションまたはサービスの 2 つのコンポーネント間の通信のために HTTP 要求で安全に送信されます。 あなたは、ID トークン内のクレームを自由に活用することができます。 通常、アカウント情報を表示したり、アプリケーションでアクセス制御の決定を行ったりするために使用されます。 Azure AD B2C によって発行された ID トークンは署名されていますが、暗号化されていません。 アプリケーションまたは API が ID トークンを受け取ったら、署名を検証してトークンが本物であることを証明する必要があります。 また、アプリケーションまたは API は、トークン内のいくつかの要求を検証して、それが有効であることを証明する必要があります。 シナリオの要件に応じて、アプリケーションによって検証される要求は異なる場合がありますが、アプリケーションでは、すべてのシナリオで一般的な要求の検証を実行する必要があります。

  • アクセス トークン - API に付与されたアクセス許可を識別するために使用できるクレームを含む JWT。 アクセス トークンは署名されますが、暗号化されません。 アクセス トークンは、API とリソース サーバーへのアクセスを提供するために使用されます。 API がアクセス トークンを受け取ったら、トークンが本物であることを証明するために署名を検証する必要があります。 また、API はトークン内のいくつかの要求を検証して、それが有効であることを証明する必要があります。 シナリオの要件に応じて、アプリケーションによって検証される要求は異なる場合がありますが、アプリケーションでは、すべてのシナリオで一般的な要求の検証を実行する必要があります。

  • 更新トークン - 更新トークンは、OAuth 2.0 フローで新しい ID トークンとアクセス トークンを取得するために使用されます。 これらのユーザーとの対話を必要とせずに、ユーザーに代わってアプリケーションにリソースへの長期的なアクセスを提供します。 更新トークンは、アプリケーションに対して不透明です。 これらは Azure AD B2C によって発行され、Azure AD B2C によってのみ検査および解釈できます。 有効期間は長いですが、更新トークンが特定の期間持続することを想定してアプリケーションを記述しないでください。 更新トークンは、さまざまな理由でいつでも無効にすることができます。 更新トークンが有効かどうかをアプリケーションが認識する唯一の方法は、Azure AD B2C にトークン要求を行って更新トークンを引き換えようとすることです。 更新トークンを新しいトークンに引き換えると、トークン応答で新しい更新トークンを受け取ります。 新しい更新トークンを保存します。 以前に要求で使用した更新トークンを置き換えます。 このアクションは、更新トークンが可能な限り有効なままであることを保証するのに役立ちます。 PKCE で承認コード フローを使用するシングルページ アプリケーションの更新トークンの有効期間は常に 24 時間です。 ブラウザーでの更新トークンのセキュリティへの影響の詳細について説明します。

エンドポイント

登録されたアプリケーションはトークンを受信し、次のエンドポイントに要求を送信して Azure AD B2C と通信します。

  • https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/authorize
  • https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/token

アプリケーションが Azure AD B2C から受け取るセキュリティ トークンは、 /authorize または /token エンドポイントから取得できます。 ID トークンが以下の場所から取得される場合:

  • /authorize エンドポイントでは、 暗黙的フローを使用して行われます。これは、JavaScript ベースの Web アプリケーションにサインインするユーザーによく使用されます。 ただし、MSAL.js 2.0 以降を使用するアプリの場合、アプリ登録で暗黙的フロー付与を有効にしないでください。これは、MSAL.js 2.0+がPKCEを使用した承認コードフローをサポートしているためです。
  • /token エンドポイントでは、 認証コード フローを使用して行われます。このフローでは、トークンがブラウザーから非表示にされます。

請求

Azure AD B2C を使用すると、トークンの内容をきめ細かく制御できます。 アプリケーションに必要なクレーム内の特定のユーザー データ セットを送信するように、ユーザー フロー と カスタム ポリシー を構成できます。 これらの要求には、 displayName や emailAddress などの標準プロパティを含めることができます。 アプリケーションでは、これらの要求を使用して、ユーザーと要求を安全に認証できます。

ID トークン内の要求は、特定の順序で返されません。 新しい要求はいつでも ID トークンに導入できます。 新しい要求が導入されるため、アプリケーションを中断しないでください。 要求に カスタム ユーザー属性を 含めることもできます。

次の表に、Azure AD B2C によって発行された ID トークンとアクセス トークンで期待できる要求の一覧を示します。

名前 主張 値の例 説明
聴衆 aud 00001111-aaaa-2222-bbbb-3333cccc4444 トークンの受信者を示します。 Azure AD B2C の場合、対象ユーザーはアプリケーション ID です。 アプリケーションはこの値を検証し、一致しない場合はトークンを拒否する必要があります。 対象ユーザーはリソースと同義です。
発行者 iss https://<tenant-name>.b2clogin.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/ トークンを構築して返すセキュリティ トークン サービス (STS) を識別します。 また、ユーザーが認証されたディレクトリも識別します。 アプリケーションでは、発行者の要求を検証して、トークンが適切なエンドポイントから取得されたことを確認する必要があります。
発行時刻 iat 1438535543 トークンが発行された時刻 。エポック時間で表されます。
期限切れ日時 exp 1438539443 トークンが無効になる時刻 (エポック時間で表されます)。 アプリケーションでは、この要求を使用してトークンの有効期間の有効性を確認する必要があります。
期間の開始時刻 nbf 1438535543 トークンが有効になる時刻をエポック時間で表します。 この時間は通常、トークンが発行された時刻と同じです。 アプリケーションでは、この要求を使用してトークンの有効期間の有効性を確認する必要があります。
バージョン ver 1.0 Azure AD B2C で定義されている ID トークンのバージョン。
コード ハッシュ c_hash SGCPtt01wxwfgnYZy2VJtQ トークンが OAuth 2.0 承認コードと共に発行された場合にのみ、ID トークンに含まれるコード ハッシュ。 コード ハッシュを使用して、承認コードの信頼性を検証できます。 この検証を実行する方法の詳細については、 OpenID Connect の仕様を参照してください。
アクセス トークン ハッシュ at_hash SGCPtt01wxwfgnYZy2VJtQ OAuth 2.0 アクセス トークンと共にトークンが発行された場合にのみ、ID トークンにアクセス トークン ハッシュが含まれます。 アクセス トークン ハッシュを使用して、アクセス トークンの信頼性を検証できます。 この検証を実行する方法の詳細については、OpenID Connect の仕様を参照してください。
nonce nonce 12345 nonce は、トークンリプレイ攻撃を軽減するために使用される戦略です。 アプリケーションでは、 nonce クエリ パラメーターを使用して、承認要求で nonce を指定できます。 要求で指定した値は、ID トークンの nonce 要求でのみ変更されていない状態で出力されます。 この要求により、アプリケーションは要求で指定された値に対して値を検証できます。 アプリケーションでは、ID トークン検証プロセス中にこの検証を実行する必要があります。
サブジェクト sub aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb トークンが情報をアサートするプリンシパル (アプリケーションのユーザーなど)。 この値は変更不可で、再割り当ても再利用もできません。 トークンを使用してリソースにアクセスする場合など、承認チェックを安全に実行するために使用できます。 既定では、サブジェクト要求には、ディレクトリ内のユーザーのオブジェクト ID が設定されます。
認証コンテキスト クラス リファレンス acr 適用なし 古いポリシーでのみ使用されます。
信頼フレームワーク ポリシー tfp b2c_1_signupsignin1 ID トークンの取得に使用されたポリシーの名前。
認証時間 auth_time 1438535543 ユーザーが最後に資格情報を入力した時刻 。エポック時間で表されます。 その認証は、新しいサインイン、シングル サインオン (SSO) セッション、または別のサインインの種類に区別されません。 auth_timeは、アプリケーション (またはユーザー) が Azure AD B2C に対する認証試行を最後に開始した時刻です。 認証に使用される方法は区別されません。
範囲 scp Read リソースに対して付与されるアクセス トークンのパーミッション。 付与された複数のアクセス許可は、スペースで区切られます。
認可済みパーティー azp 975251ed-e4f5-4efd-abcb-5f1a8f566ab7 要求を開始したクライアント アプリケーションのアプリケーション ID 。

コンフィギュレーション

次のプロパティは、Azure AD B2C によって出力される セキュリティ トークンの有効期間を管理 するために使用されます。

  • アクセスと ID トークンの有効期間 (分) - 保護されたリソースへのアクセスを取得するために使用される OAuth 2.0 ベアラー トークンの有効期間。 既定値は 60 分です。 最短は 5 分 (含む) です。 最大値 (含む) は 1,440 分です。

  • 更新トークンの有効期間 (日数) - 更新トークンを使用して新しいアクセストークンまたは ID トークンを取得できるまでの最大期間。 この期間では、アプリケーションに offline_access スコープが付与されている場合の新しい更新トークンの取得についても説明します。 既定値は 14 日です。 最短は 1 日 (含む) です。 最大 (含む) は 90 日です。

  • 更新トークンのスライディング ウィンドウの有効期間 (日数) - この期間が経過すると、アプリケーションによって取得された最新の更新トークンの有効期間に関係なく、ユーザーは強制的に再認証されます。 スイッチが Bounded に設定されている場合にのみ指定できます。 更新トークンの有効期間 (日) の値以上である必要があります。 スイッチが [有効期限なし] に設定されている場合、特定の値を指定することはできません。 既定値は 90 日です。 最短は 1 日 (含む) です。 最大 (含む) は 365 日です。

これらのプロパティを使用して、次のユース ケースが有効になります。

  • ユーザーがアプリケーションで継続的にアクティブである限り、ユーザーがモバイル アプリケーションに無期限にサインインし続けることができます。 サインイン ユーザー フローでは、 更新トークンのスライディング ウィンドウの有効期間 (日数) を [有効期限なし ] に設定できます。
  • 適切なアクセス トークンの有効期間を設定して、業界のセキュリティとコンプライアンスの要件を満たします。

これらの設定は、パスワード リセット ユーザー フローでは使用できません。

互換性

トークンの互換性を管理するには、次のプロパティを使用します。

  • 発行者 (iss) 要求 - このプロパティは、トークンを発行した Azure AD B2C テナントを識別します。 既定値は https://<domain>/{B2C tenant GUID}/v2.0/ です。 https://<domain>/tfp/{B2C tenant GUID}/{Policy ID}/v2.0/の値には、Azure AD B2C テナントと、トークン要求で使用されたユーザー フローの両方の ID が含まれます。 アプリケーションまたはライブラリで Azure AD B2C が OpenID Connect Discovery 1.0 仕様に準拠している必要がある場合は、この値を使用します。

  • サブジェクト (サブ) 要求 - このプロパティは、トークンが情報をアサートするエンティティを識別します。 既定値は ObjectID で、トークン内の sub 要求にユーザーのオブジェクト ID が設定されます。 [サポートされていません] の値は、下位互換性のためにのみ提供されます。 可能になったらすぐに ObjectID に切り替えるようにすることをお勧めします。

  • ポリシー ID を表す要求 - このプロパティは、トークン要求で使用されるポリシー名が設定される要求の種類を識別します。 既定値は tfp です。 acrの値は、下位互換性のためにのみ提供されます。

パススルー

ユーザー体験が開始されると、Azure AD B2C は ID プロバイダーからアクセス トークンを受け取ります。 Azure AD B2C は、そのトークンを使用してユーザーに関する情報を取得します。 ユーザー フローで要求を有効にして、Azure AD B2C に登録したアプリケーションに トークンを渡します 。 トークンを要求として渡すことを利用するには、アプリケーションで 推奨されるユーザー フロー を使用する必要があります。

現在、Azure AD B2C では、Facebook や Google を含む OAuth 2.0 ID プロバイダーのアクセス トークンの渡しのみがサポートされています。 他のすべての ID プロバイダーの場合、要求は空白で返されます。

検証

トークンを検証するには、アプリケーションでトークンの署名と要求の両方を確認する必要があります。 JWT の検証には、好みの言語に応じて、多くのオープンソース ライブラリを使用できます。 独自の検証ロジックを実装するのではなく、これらのオプションを探索することをお勧めします。

署名を検証する

JWT には、 ヘッダー、 本文、 および署名の 3 つのセグメントが含まれています。 署名セグメントを使用してトークンの信頼性を検証し、アプリケーションから信頼できるようにすることができます。 Azure AD B2C トークンは、RSA 256 などの業界標準の非対称暗号化アルゴリズムを使用して署名されます。

トークンのヘッダーには、トークンの署名に使用されるキーと暗号化方法に関する情報が含まれています。

{
        "typ": "JWT",
        "alg": "RS256",
        "kid": "GvnPApfWMdLRi8PDmisFn7bprKg"
}

alg 要求の値は、トークンの署名に使用されたアルゴリズムです。 kid 要求の値は、トークンの署名に使用された公開キーです。 Azure AD B2C はいつでも、公開キーと秘密キーのペアのセットのいずれかを使用してトークンに署名できます。 Azure AD B2C は、使用可能なキーのセットを定期的にローテーションします。 これらのキーの変更を自動的に処理するようにアプリケーションを記述する必要があります。 Azure AD B2C で使用される公開キーの更新を確認する妥当な頻度は、24 時間ごとに行われます。 予期しないキーの変更を処理するには、予期しない キッド 値を受け取った場合に公開キーを再取得するようにアプリケーションを書き込む必要があります。

Azure AD B2C には、OpenID Connect メタデータ エンドポイントがあります。 このエンドポイントを使用して、アプリケーションは実行時に Azure AD B2C に関する情報を要求できます。 この情報には、エンドポイント、トークンの内容、トークンの署名キーが含まれます。 Azure AD B2C テナントには、ポリシーごとに JSON メタデータ ドキュメントが含まれています。 メタデータ ドキュメントは、いくつかの有用な情報を含む JSON オブジェクトです。 メタデータには 、トークンの署名に使用される公開キーのセットの場所を示すjwks_uriが含まれています。 この場所はここで提供されますが、メタデータ ドキュメントを使用して場所を動的にフェッチし、jwks_uri解析することをお勧 めします。

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/discovery/v2.0/keys

この URL にある JSON ドキュメントには、特定の時点で使用されているすべての公開キー情報が含まれています。 アプリでは、JWT ヘッダーの kid 要求を使用して、特定のトークンの署名に使用される JSON ドキュメントの公開キーを選択できます。 その後、正しい公開キーと指定されたアルゴリズムを使用して、署名の検証を実行できます。

contoso.onmicrosoft.com テナントのB2C_1_signupsignin1 ポリシーのメタデータ ドキュメントは、次の場所にあります。

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/v2.0/.well-known/openid-configuration

トークンの署名に使用されたポリシー (およびメタデータを要求する場所) を特定するには、2 つのオプションがあります。 最初に、ポリシー名はトークンの tfp (既定) または acr 要求 (構成済み) に含まれます。 base-64 で本文をデコードし、結果として返される JSON 文字列を逆シリアル化することで、JWT の本文から要求を解析できます。 tfpまたはacr要求は、トークンの発行に使用されたポリシーの名前です。 もう 1 つのオプションは、要求を発行するときに、 state パラメーターの値でポリシーをエンコードし、それをデコードして使用されたポリシーを特定することです。 どちらの方法も有効です。

Azure AD B2C では、 RFC 3447 仕様に基づく RS256 アルゴリズムが使用されます。 公開キーは、RSA 剰余 (n) と RSA 公開指数 (e) の 2 つのコンポーネントで構成されます。 n値とe値をトークン検証用の証明書形式にプログラムで変換できます。

署名の検証を実行する方法の説明は、このドキュメントの範囲外です。 トークンの検証に役立つ多くのオープン ソース ライブラリを使用できます。

要求の検証

アプリケーションまたは API が ID トークンを受け取ると、ID トークン内の要求に対していくつかのチェックも実行する必要があります。 次の要求を確認する必要があります。

  • audience - ID トークンがアプリケーションに提供されることを確認します。
  • 前と有効期限ではありません - ID トークンの有効期限が切れていないことを確認します。
  • issuer - トークンが Azure AD B2C によってアプリケーションに発行されたことを確認します。
  • nonce - トークンリプレイ攻撃軽減のための戦略。

アプリケーションで実行する必要がある検証の完全な一覧については、 OpenID Connect の仕様を参照してください。

関連コンテンツ

アクセス トークンの使用方法の詳細について説明します。