Azure Active Directory B2C での OpenID Connect による Web サインイン
OpenID Connect は、ユーザーを Web アプリケーションに安全にサインインさせるために使用できる、OAuth 2.0 に基づいて構築された認証プロトコルです。 Azure Active Directory B2C (Azure AD B2C) で導入された OpenID Connect を利用することで、Web アプリケーションのサインアップ、サインイン、その他の ID 管理を Microsoft Entra ID に外注できます。 このガイドでは、これを言語に依存しない方法で実行する方法について説明します。 オープンソース ライブラリを利用しないで、HTTP メッセージを送受信する方法について説明します。
注意
オープンソース認証ライブラリのほとんどで、アプリケーションの JWT トークンの取得と検証が行われます。 独自のコードを実装するより、オープンソース ライブラリを試してみることをお勧めします。 詳しくは、「Microsoft Authentication Library (MSAL) の概要」と「Microsoft Identity Web 認証ライブラリ」を参照してください。
OpenID Connect は、OAuth 2.0 の "認可" プロトコルを "認証" プロトコルとして使用できるように拡張したものです。 この認証プロトコルでは、シングル サインオンを実行できます。 ここでは、クライアントがユーザーの ID を検証したり、ユーザーに関する基本的なプロファイル情報を取得したりできるようにする "ID トークン" の概念が導入されています。
OpenID Connect により、アプリケーションがアクセス トークンを安全に取得することも可能になります。 アクセス トークンを使用すると、承認サーバーによってセキュリティ保護されたリソースにアクセスできます。 サーバーでホストされ、ブラウザーでアクセスされる Web アプリケーションを構築する場合は、OpenID Connect をお勧めします。 トークンの詳細については、「Overview of tokens in Azure Active Directory B2C (Azure Active Directory B2C でのトークンの概要)」を参照してください。
Azure AD B2C は、単純な認証と権限付与以上のことができるように標準の OpenID Connect プロトコルを拡張したものです。 これによって導入されるユーザー フロー パラメーターにより、OpenID Connect を使用してサインアップ、サインイン、プロファイル管理などのユーザー エクスペリエンスをアプリに追加できるようになります。
認証要求を送信する
ご利用の Web アプリケーションでユーザーを認証し、ユーザー フローを実行する必要があるときは、ユーザーを /authorize エンドポイントにリダイレクトさせることができます。 ユーザーはユーザー フローに応じてアクションを実行します。
この要求では、クライアントによって、ユーザーから取得する必要があるアクセス許可が scope パラメーターで示され、実行するユーザー フローが指定されます。 要求がどのように動作するかを理解するには、要求をブラウザーに貼り付けて実行してください。 置換前のコード:
{tenant}を自分のテナントに置き換えます。90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6を、テナントに登録済みのアプリケーションのアプリ ID に置き換えます。{application-id-uri}/{scope-name}を、テナントに登録済みのアプリケーションのアプリケーション ID URI とスコープに置き換えます。{policy}を、テナント内のポリシー名に置き換えます (例:b2c_1_sign_in)。
GET /{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
Host: {tenant}.b2clogin.com
client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=code+id_token
&redirect_uri=https%3A%2F%2Fjwt.ms%2F
&response_mode=fragment
&scope=openid%20offline_access%20{application-id-uri}/{scope-name}
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
| パラメーター | 必須 | 説明 |
|---|---|---|
| {tenant} | はい | Azure AD B2C テナントの名前。 カスタム ドメインを使用している場合は、tenant.b2clogin.com を自分のドメイン (例: fabrikam.com) に置き換えます。 |
| {policy} | はい | アプリが実行するユーザー フローまたはポリシー。 Azure AD B2C テナントに作成したユーザー フローの名前を指定します。 例: b2c_1_sign_in、b2c_1_sign_up、またはb2c_1_edit_profile。 |
| client_id | はい | Azure portal によってアプリケーションに割り当てられたアプリケーション ID。 |
| nonce | はい | 要求に追加する (アプリケーションによって生成された) 値。この値が、最終的な ID トークンに要求として追加されます。 アプリケーションでこの値を確認することにより、トークン再生攻撃を緩和することができます。 この値は通常、要求の送信元を識別するために使用できるランダム化された一意の文字列です。 |
| response_type | はい | OpenID Connect の ID トークンが含まれている必要があります。 Web アプリケーションが Web API を呼び出すためのトークンも必要とする場合は、code+id_token を使用します。 |
| scope | はい | スコープのスペース区切りリスト。 openid スコープは、ユーザーをサインインさせ、ID トークンの形式でユーザーに関するデータを取得するためのアクセス許可を示します。 Web アプリケーションの場合、offline_access スコープは任意です。 これは、リソースへのアクセス期間を延長するには、アプリケーションで "更新トークン" が必要であることを示します。 https://{tenant-name}/{app-id-uri}/{scope} は、保護されたリソース (Web API など) に対するアクセス許可を示します。 詳細については、アクセス トークンを要求するを参照してください。 |
| prompt | いいえ | ユーザーに要求する対話の種類。 現時点で有効な値は login だけです。これはユーザーに、その要求に関する資格情報を強制的に入力させます。 |
| redirect_uri | はい | アプリケーションの redirect_uri パラメーター。これにより、サーバーはアプリケーションに認証応答を送信できます。 これは、URL エンコードされている必要がある点を除き、Azure portal で登録した redirect_uri パラメーターのいずれかに正確に一致している必要があります。 |
| response_mode | いいえ | 結果として得られた承認コードをアプリケーションに送り返すために使用される方法。 これは query、form_post、fragment のいずれかにできます。 最高のセキュリティを得るには、form_post 応答モードをお勧めします。 |
| state | いいえ | 承認サーバーがトークン応答で返す要求に含めることができる値。 任意の文字列を指定することができます。 クロスサイト リクエスト フォージェリ攻撃を防ぐために通常、ランダムに生成された一意の値が使用されます。 この状態は、認証要求の前にアプリケーション内でユーザーの状態 (表示中のページなど) に関する情報をエンコードする目的にも使用されます。 Azure portal に複数のリダイレクト URL を登録したくない場合は、state パラメーターを使用することで、要求の違いにより Azure AD B2C サービスからアプリケーションの応答を区別できます。 |
| login_hint | いいえ | サインイン ページのサインイン名フィールドに事前に入力するために使用できます。 詳細については、「サインイン名を事前入力する」を参照してください。 |
| domain_hint | いいえ | サインインに使用する必要があるソーシャル ID プロバイダーに関するヒントを Azure AD B2C に提供します。 有効な値が含まれている場合、ユーザーは直接 ID プロバイダーのサインイン ページに移動します。 詳細については、「サインインをソーシャル プロバイダーにリダイレクトする」を参照してください。 |
| カスタム パラメーター | いいえ | カスタムポリシーで使用できるカスタム パラメーター。 例: 動的なカスタム ページ コンテンツ URI、またはキー値要求リゾルバー。 |
この時点で、ユーザーはワークフローを完了するよう求められます。 ユーザー名とパスワードを入力したり、ソーシャル ID でサインインしたり、ディレクトリにサインアップしたりすることが必要な場合があります。 ユーザー フローの定義方法によっては、これ以外にもいくつかの手順が必要になる場合があります。
ユーザーがユーザー フローを完了すると、response_mode パラメーターで指定された方法を使用して、redirect_uri パラメーターで示された場所にあるアプリケーションに応答が返されます。 ユーザー フローには関係なく、応答は前の各ケースにおいて同じです。
response_mode=fragment を使用した場合の正常な応答は次のようになります。
GET https://jwt.ms/#
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=arbitrary_data_you_can_receive_in_the_response
| パラメーター | 説明 |
|---|---|
| id_token | アプリケーションが要求した ID トークン。 この ID トークンを使用してユーザーの本人性を確認し、そのユーザーとのセッションを開始することができます。 |
| code | アプリケーションが要求した承認コード (response_type=code+id_token を使用した場合)。 アプリケーションは承認コードを使用して、対象リソースのアクセス トークンを要求します。 承認コードは、通常 10 分程度で期限切れとなります。 |
| state | 要求に state パラメーターが含まれている場合、同じ値が応答にも含まれることになります。 アプリケーションでは、要求と応答の state 値が同一であることを検証する必要があります。 |
アプリケーションでエラーを適切に処理できるように、redirect_uri パラメーターにはエラー応答も送信されます。
GET https://jwt.ms/#
error=access_denied
&error_description=AADB2C90091%3a+The+user+has+cancelled+entering+self-asserted+information.%0d%0aCorrelation+ID%3a+xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx%0d%0aTimestamp%3a+xxxx-xx-xx+xx%3a23%3a27Z%0d%0a
&state=arbitrary_data_you_can_receive_in_the_response
| パラメーター | 説明 |
|---|---|
| error | 発生したエラーの種類を分類するために使用できるコード。 |
| error_description | 認証エラーの根本的な原因を特定するのに役立つ具体的なエラー メッセージ。 |
| state | 要求に state パラメーターが含まれている場合、同じ値が応答にも含まれることになります。 アプリケーションでは、要求と応答の state 値が同一であることを検証する必要があります。 |
ID トークンの検証
ユーザーを認証するには、ID トークンを受信するだけでは不十分です。 ID トークンの署名を検証し、アプリケーションの要件ごとにトークン内の要求を確認します。 Azure AD B2C は、JSON Web トークン (JWT) と公開キー暗号を使用してトークンに署名し、それらが有効であることを証明します。
Note
オープンソース認証ライブラリのほとんどで、アプリケーションの JWT トークンの検証が行われます。 独自の検証ロジックを実装するより、オープンソース ライブラリを試してみることをお勧めします。 詳しくは、「Microsoft Authentication Library (MSAL) の概要」と「Microsoft Identity Web 認証ライブラリ」を参照してください。
Azure AD B2C には、OpenID Connect メタデータ エンドポイントがあって、アプリケーションは、このエンドポイントを使用することで、Azure AD B2C に関する情報を実行時に取得することができます。 この情報には、エンドポイント、トークンの内容、トークンの署名キーが含まれます。 B2C テナントにはユーザー フローごとに JSON メタデータ ドキュメントがあります。 たとえば、fabrikamb2c.onmicrosoft.com 内の b2c_1_sign_in ユーザー フローのメタデータ ドキュメントは次の場所にあります。
https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/v2.0/.well-known/openid-configuration
この構成ドキュメントのプロパティの 1 つに jwks_uri があります。同じユーザー フローに対するこの値は次のようになります。
https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/discovery/v2.0/keys
どのユーザー フローが ID トークンの署名に使用されたかは、2 つの方法で判断できます。 1 つ目として、ID トークンの acr 要求にユーザー フロー名が含まれています。ユーザー フローを表す要求に関する説明をご覧ください。 もう 1 つの選択肢では、要求を発行するときに state パラメーターの値に含まれているユーザー フローをエンコードして、それをデコードして使用されたユーザー フローを判断します。 どちらの方法も有効です。
OpenID Connect メタデータ エンドポイントからメタデータ ドキュメントを取得したら、RSA 256 公開キーを利用し、ID トークンの署名を検証できます。 このエンドポイントには、それぞれが kid 要求によって識別されるキーが複数存在すると表示される場合があります。 また、ID トークンのヘッダーには、これらのキーのうちのどれが ID トークンの署名に使用されたかを示す kid 要求も含まれています。
Azure AD B2C からのトークンを確認するには、指数 (e) と剰余 (n) を使用して公開キーを生成する必要があります。 そのためには、任意のプログラミング言語で公開キーを生成する方法を学習する必要があります。 RSA プロトコルを使用した公開キーの生成に関する公式ドキュメントについては、https://tools.ietf.org/html/rfc3447#section-3.1 を参照してください。
ID トークンの署名を検証した後、確認する必要のあるさまざまな要求が存在します。 次に例を示します。
- トークン再生攻撃を防止するために、
nonce要求を検証します。 その値が、サインイン要求で指定した値と一致していることが必要です。 - ID トークンが自分のアプリケーションのために発行されたことを確認するために、
aud要求を検証します。 その値がアプリケーションのアプリケーション ID と一致している必要があります。 - ID トークンの有効期限が切れていないことを確認するために、
iat要求とexp要求を検証します。
また、実行する必要のあるその他の検証もいつくか存在します。 検証の詳細については、OpenID Connect コアの仕様に関するページを参照してください。シナリオに応じてその他の要求も検証することができます。 以下に一般的な検証の例をいくつか挙げます。
- ユーザー/組織がアプリにサインアップ済みであることを確認する。
- 適切な認可/権限がユーザーにあることを確認する。
- Microsoft Entra 多要素認証など特定の強度の認証が行われたことを確認する。
ID トークンが検証された後、ユーザーとのセッションを開始できます。 ID トークン内の要求を使用して、アプリケーションでユーザーに関する情報を取得できます。 この情報の使用には、表示、記録、および承認が含まれます。
トークンを取得する
Web アプリケーションがユーザー フローの実行にのみ必要な場合は、次のいくつかのセクションを省略できます。 これらのセクションは、Azure AD B2C 自体によって保護されている Web API に対して認証された呼び出しを行う必要がある Web アプリケーションにのみ適用されます。
トークン用に (response_type=code+id_token を使用して) 取得した承認コードは、POST 要求を /token エンドポイントに送信することによって目的のリソースに利用できます。 Azure AD B2C では、対応するスコープを要求の中で指定することによって、いつものように他の API のアクセス トークンを要求できます。
アプリ独自のバックエンド Web API のアクセス トークンを要求することもできます。 この場合、要求されたスコープとしてアプリのクライアント ID を使用します。その結果、そのクライアント ID を "対象ユーザー" として持つアクセス トークンが生成されます。
POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
| パラメーター | 必須 | 説明 |
|---|---|---|
| {tenant} | はい | Azure AD B2C テナントの名前。 |
| {policy} | はい | 認証コードの取得に使用されたユーザー フロー。 この要求に別のユーザー フローを使用することはできません。 このパラメーターを POST 本文ではなく、クエリ文字列に追加します。 |
| client_id | はい | Azure portal によってアプリケーションに割り当てられたアプリケーション ID。 |
| client_secret | はい (Web アプリの場合) | Azure portal で生成されたアプリケーション シークレット。 クライアントが安全にクライアント シークレットを格納できる Web アプリのシナリオでは、このフローでクライアント シークレットが使用されます。 ネイティブ アプリ (パブリック クライアント) のシナリオでは、クライアント シークレットを安全に保存できないため、このフローでは使用されません。 クライアント シークレットを使用する場合は、定期的に変更してください。 |
| コード | はい | ユーザー フローの開始時に取得した承認コード。 |
| grant_type | はい | 許可の種類。承認コード フローでは authorization_code を指定する必要があります。 |
| redirect_uri | いいえ | 承認コードを受信したアプリケーションの redirect_uri パラメーター。 |
| scope | いいえ | スコープのスペース区切りリスト。 openid スコープは、ユーザーをサインインさせ、ユーザーに関するデータを id_token パラメーターの形式で取得するためのアクセス許可を示します。 これを使用すると、クライアントと同じアプリケーション ID で表される、アプリケーションの独自のバックエンド Web API にトークンを送信できます。 offline_access スコープは、リソースへのアクセス期間を延長するには、アプリケーションで更新トークンが必要であることを示します。 |
正常なトークン応答は次のようになります。
{
"not_before": "1442340812",
"token_type": "Bearer",
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
"scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
"expires_in": "3600",
"expires_on": "1644254945",
"refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
| パラメーター | 説明 |
|---|---|
| not_before | トークンが有効になるエポック時間。 |
| token_type | トークン タイプ値。 Bearer は、サポートされる唯一のタイプです。 |
| access_token | 要求した署名付きの JWT トークン。 |
| scope | トークンの有効なスコープ。 |
| expires_in | アクセス トークンが有効な時間の長さ (秒単位)。 |
| expires_on | アクセス トークンが無効になるエポック時間。 |
| refresh_token | OAuth 2.0 更新トークン。 現在のトークンの有効期限が切れた後、アプリケーションでは、このトークンを使用してさらにトークンが取得されます。 更新トークンを使用すると、期間を延長してリソースにアクセスし続けることができます。 更新トークンを受信するには、承認要求とトークン要求の両方でスコープ offline_access を使用する必要があります。 |
エラー応答は次のようになります。
{
"error": "invalid_grant",
"error_description": "AADB2C90080: The provided grant has expired. Please re-authenticate and try again. Current time: xxxxxxxxxx, Grant issued time: xxxxxxxxxx, Grant expiration time: xxxxxxxxxx\r\nCorrelation ID: xxxxxxxx-xxxx-xxxX-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-16 xx:10:52Z\r\n"
}
| パラメーター | 説明 |
|---|---|
| error | 発生したエラーの種類を分類するために使用できるコード。 |
| error_description | 認証エラーの根本的な原因を特定するのに役立つメッセージ。 |
トークンを使用する
アクセス トークンを正常に取得できたら、そのトークンを Authorization ヘッダー内に含めることによって、それをバックエンド Web API への要求で使用できます。
GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
トークンを更新する
アクセス トークンと ID トークンの有効期限は非常に短いです。 有効期限が切れた後に、リソースに引き続きアクセスできるようにするには、トークンを更新する必要があります。 アクセス トークンを更新すると、Azure AD B2C から新しいトークンが返されます。 更新されたアクセス トークンは、nbf (期間の開始時刻)、iat (発行時刻)、および exp (有効期限) の要求値が更新されます。 他のすべての要求値は、前のアクセス トークンの値と似ています。
トークンを更新するには、もう一度 POST 要求を /token エンドポイントに送信します。 今回は、code パラメーターの代わりに refresh_token パラメーターを指定します。
POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=openid offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
| パラメーター | 必須 | 説明 |
|---|---|---|
| {tenant} | はい | Azure AD B2C テナントの名前。 |
| {policy} | はい | 元の更新トークンの取得に使用されたユーザー フロー。 この要求に別のユーザー フローを使用することはできません。 このパラメーターを POST 本文ではなく、クエリ文字列に追加します。 |
| client_id | はい | Azure portal によってアプリケーションに割り当てられたアプリケーション ID。 |
| client_secret | はい (Web アプリの場合) | Azure portal で生成されたアプリケーション シークレット。 クライアントが安全にクライアント シークレットを格納できる Web アプリのシナリオでは、このフローでクライアント シークレットが使用されます。 ネイティブ アプリ (パブリック クライアント) のシナリオでは、クライアント シークレットを安全に保存できないため、この呼び出しでは使用されません。 クライアント シークレットを使用する場合は、定期的に変更してください。 |
| grant_type | はい | 許可の種類。承認コード フローのこの部分の refresh_token を指定する必要があります。 |
| refresh_token | はい | フローの第 2 のパートで取得された元の更新トークン。 更新トークンを受信するには、承認要求とトークン要求の両方でスコープ offline_access を使用する必要があります。 |
| redirect_uri | いいえ | 承認コードを受信したアプリケーションの redirect_uri パラメーター。 |
| scope | いいえ | スコープのスペース区切りリスト。 openid スコープは、ユーザーをサインインさせ、ID トークンの形式でユーザーに関するデータを取得するためのアクセス許可を示します。 これを使用すると、クライアントと同じアプリケーション ID で表される、アプリケーションの独自のバックエンド Web API にトークンを送信できます。 offline_access スコープは、リソースへのアクセス期間を延長するには、アプリケーションで更新トークンが必要であることを示します。 |
正常なトークン応答は次のようになります。
{
"not_before": "1442340812",
"token_type": "Bearer",
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
"scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
"expires_in": "3600",
"refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
"refresh_token_expires_in": "1209600"
}
| パラメーター | 説明 |
|---|---|
| not_before | トークンが有効になるエポック時間。 |
| token_type | トークン タイプ値。 Bearer は、サポートされる唯一のタイプです。 |
| access_token | 要求された署名付きの JWT トークン。 |
| scope | トークンの有効なスコープ。 |
| expires_in | アクセス トークンが有効な時間の長さ (秒単位)。 |
| refresh_token | OAuth 2.0 更新トークン。 現在のトークンの有効期限が切れた後、アプリケーションでは、このトークンを使用して、追加のトークンが取得されます。 更新トークンを使用すると、期間を延長してリソースにアクセスし続けることができます。 |
| refresh_token_expires_in | 更新トークンが有効な時間の長さ (秒単位)。 |
エラー応答は次のようになります。
{
"error": "invalid_grant",
"error_description": "AADB2C90129: The provided grant has been revoked. Please reauthenticate and try again.\r\nCorrelation ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-xx xx:xx:xxZ\r\n",
}
| パラメーター | 説明 |
|---|---|
| error | 発生したエラーの種類を分類するために使用できるコード。 |
| error_description | 認証エラーの根本的な原因を特定するのに役立つメッセージ。 |
サインアウト要求を送信する
ユーザーをアプリケーションからサインアウトさせるときは、アプリケーションの Cookie を消去する、あるいはユーザーとのセッションを終了するだけでは十分ではありません。 サインアウトさせるには、ユーザーを Azure AD B2C にリダイレクトします。そうしない場合、ユーザーは資格情報を再入力しなくてもアプリケーションに対して再認証できることがあります。 詳しくは、Azure AD B2C のセッションの動作に関する記事を参照してください。
ユーザーをサインアウトするには、前述した OpenID Connect メタデータ ドキュメントに示されている end_session_endpoint にユーザーをリダイレクトします。
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Fjwt.ms%2F
| パラメーター | 必須 | 説明 |
|---|---|---|
| {tenant} | はい | Azure AD B2C テナントの名前。 カスタム ドメインを使用している場合は、tenant.b2clogin.com を自分のドメイン (例: fabrikam.com) に置き換えます。 |
| {policy} | はい | 認可要求で指定したユーザー フロー。 たとえば、ユーザーが b2c_1_sign_in ユーザー フローでサインインした場合は、サインアウト要求で b2c_1_sign_in を指定します。 |
| id_token_hint | いいえ | エンド ユーザーのクライアントとの現在の認証済みセッションに関するヒントとしてログアウトエンド ポイントに渡される発行済みの ID トークン。 id_token_hint によって、post_logout_redirect_uri が Azure AD B2C アプリケーション設定に登録済みの応答 URL であることが確認されます。 詳細については、「ログアウトのリダイレクトをセキュリティで保護する」を参照してください。 |
| client_id | いいえ* | Azure portal によってアプリケーションに割り当てられたアプリケーション ID。 *これは、 Application の分離の SSO 構成を使用し、 [ログアウト要求に ID トークンが必要] が No に設定されている場合に必要となります。 |
| post_logout_redirect_uri | いいえ | サインアウトの正常終了後にユーザーをリダイレクトする URL。これが含まれていない場合、Azure AD B2C では、ユーザーに対して一般的なメッセージが表示されます。 id_token_hint を指定しない限り、この URL を Azure AD B2C アプリケーション設定に応答 URL として登録することはできません。 |
| state | いいえ | state パラメーターが認可要求に含まれている場合は、post_logout_redirect_uri への応答で同じ値が返されます。 アプリケーションでは、要求と応答の state 値が同一であることを検証する必要があります。 |
サインアウト要求が発生すると、Azure AD B2C は Azure AD B2C Cookie ベースのセッションを無効にし、フェデレーション ID プロバイダーからのサインアウトを試行します。 詳細については、「シングル サインアウト」をご覧ください。
ログアウトのリダイレクトをセキュリティで保護する
ログアウト後、ユーザーは、アプリケーションに対して指定されている応答 URL に関係なく、post_logout_redirect_uri パラメーターに指定された URI にリダイレクトされます。 ただし、有効な id_token_hint が渡され、 [ログアウト要求に ID トークンが必要] が有効になっている場合、Azure AD B2C では、リダイレクトの実行前に、post_logout_redirect_uri の値がいずれかのアプリケーションの構成済みのリダイレクト URL と一致するかどうかが検証されます。 一致する応答 URL がアプリケーションで構成されていない場合は、エラー メッセージが表示され、ユーザーはリダイレクトされません。
ログアウト要求に必要な ID トークンを設定するには、「Azure Active Directory B2C でセッションの動作を構成する」を参照してください。
次のステップ
- Azure AD B2C セッションの詳細について学習します。