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

[アーティクル]
04/24/2023

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 エンドポイントの場合、承認コードフローを使用して行われます。これにより、ブラウザーからはトークンが非表示になります。

Claims

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

ID トークン内のクレームは特定の順序では返されません。新しい要求が ID トークンに導入される可能性が常にあります。新しい要求が導入されたときに、アプリケーションで問題が起きないようにする必要があります。要求にカスタムユーザー属性を含めることもできます。

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

名前	要求	値の例	説明
対象ユーザー	`aud`	`90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6`	トークンの受信者を示します。 Azure AD B2C では、対象ユーザーはアプリケーション ID です。アプリケーションでは、この値を検証し、一致しない場合はトークンを拒否する必要があります。対象ユーザーは、リソースと同義です。
発行者	`iss`	`https://<tenant-name>.b2clogin.com/775527ff-9a37-4307-8b3d-cc311f58d925/v2.0/`	トークンを構築して返す Security Token Service (STS) を識別します。また、ユーザーが認証されたディレクトリも識別します。アプリケーションでは、発行者要求を検証し、トークンが適切なエンドポイントからのものであることを確認する必要があります。
発行時刻	`iat`	`1438535543`	トークンが発行された日時です。エポック時間で表されます。
期限切れ日時	`exp`	`1438539443`	トークンが無効になる日時です。エポック時間で表されます。アプリケーションでは、この要求を使用してトークンの有効期間の有効性を確認する必要があります。
期間の開始時刻	`nbf`	`1438535543`	トークンが有効になる日時です。エポック時間で表されます。この日時は、通常、トークンが発行されたのと同じ日時です。アプリケーションでは、この要求を使用してトークンの有効期間の有効性を確認する必要があります。
Version	`ver`	`1.0`	ID トークンのバージョンです。Azure AD B2C で定義されています。
コードハッシュ	`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`	`884408e1-2918-4cz0-b12d-3aa027d7563b`	トークンが情報をアサートするプリンシパル (アプリケーションのユーザーなど)。この値は変更不可で、再割り当ても再利用もできません。そのため、この値を使用すると、トークンを使用してリソースにアクセスする場合などに安全に承認チェックができます。既定では、サブジェクト要求には、ディレクトリ内のユーザーのオブジェクト ID が設定されます。
認証コンテキストクラスの参照	`acr`	適用なし	古いポリシーでのみ使用されます。
信頼フレームワークポリシー	`tfp`	`b2c_1_signupsignin1`	ID トークンの取得に使用されたポリシーの名前。
認証時刻	`auth_time`	`1438535543`	ユーザーが資格情報を最後に入力した時刻。エポック時間で表されます。認証が新規サインイン、シングルサインオン (SSO) セッション、または別のサインインの種類のいずれであるかの区別はありません。 `auth_time` は、アプリケーション (またはユーザー) が Azure AD B2C に対して認証の試行を開始した最後の時刻です。認証に使用される方法は区別されません。
Scope	`scp`	`Read`	アクセストークンで付与されるリソースへのアクセス許可。付与される複数のアクセス許可はスペースで区切られます。
Authorized Party	`azp`	`975251ed-e4f5-4efd-abcb-5f1a8f566ab7`	要求を開始したクライアントアプリケーションのアプリケーション ID。

構成

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

[アクセスと ID トークンの有効期間 (分)] - 保護されたリソースへのアクセスを取得するために使用される OAuth 2.0 ベアラートークンの有効期間。既定値は 60 分です。最短は 5 分以内です。最長は 1,440 分以内です。
[更新トークンの有効期間 (日)] - 新しいアクセスまたは ID トークンの取得に更新トークンを使用できる最大期間です。アプリケーションに offline_access スコープが付与されている場合は、この期間中に新しい更新トークンの取得もできます。既定値は 14 日です。最短は 1 日以内です。最長は 90 日以内です。
[更新トークンのスライディングウィンドウの有効期間 (日)] - この期間が経過すると、アプリケーションによって取得された最新の更新トークンの有効期間には関係なく、ユーザーは強制的に再認証を求められます。スイッチが [制限あり] の場合にのみ、この設定が可能です。 [Refresh token lifetime (days) (更新トークン有効期間 (日))] の値以上であることが必要です。スイッチが [期限なし] に設定されている場合は、特定の値を指定できません。既定値は 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 仕様に準拠させる必要がある場合は、この値を使用します。
[サブジェクト (sub) 要求] - このプロパティは、トークンが情報をアサートするエンティティを識別します。既定値は 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 時間に 1 回です。予期しないキーの変更を処理するには、予期しない kid 値を受信したときに公開キーを再取得するようにアプリケーションを記述する必要があります。

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 つの方法があります。 1 つめは、ポリシー名がトークンの 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 トークン内の要求に対していくつかのチェックを実行する必要があります。以下の要求が確認される必要があります。

対象ユーザー - ID トークンが特定のアプリケーションを対象に発行されたものであることを検証します。
期間の開始時刻および期限切れ日時 - ID トークンが期限切れでないことを検証します。
発行者 - トークンが Azure AD B2C によって自分のアプリケーションに対して発行されたことを検証します。
nonce - トークンリプレイ攻撃を緩和するための戦略です。

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

次のステップ

アクセストークンを使用する方法の詳細を学習してください。

次の方法で共有