OpenID Connect による Web サインイン - Azure Active Directory B2C

[アーティクル]
01/11/2024

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 セッションの詳細について学習します。

Azure Active Directory B2C での OpenID Connect による Web サインイン