Microsoft ID プラットフォームでの OpenID Connect
OpenID Connect (OIDC) は、OAuth 2.0 の認可プロトコルを別の認証プロトコルとして使用できるように拡張したものです。 OIDC を使用し、"ID トークン" と呼ばれるセキュリティ トークンを使用することで、OAuth 対応アプリケーション間でシングル サインオン (SSO) を有効にすることができます。
OIDC の完全な仕様は、OpenID Foundation の Web サイト (OpenID Connect Core 1.0 の仕様に関するページ) で入手できます。
プロトコル フロー: サインイン
以下の図は、OpenID Connect の基本的なサインイン フローを示しています。 フローの手順については、記事の後半のセクションで詳しく説明します。
ID トークンを有効にする
OpenID Connect によって導入された "ID トークン" は、クライアント アプリケーションがユーザー認証中に ID トークンを要求したときに、承認サーバー (Microsoft ID プラットフォーム) によって発行されます。 ID トークンによって、クライアント アプリケーションはユーザーが本人であることを確認でき、そのユーザーに関するその他の情報 (要求) を取得できます。
ID トークンは、Microsoft ID プラットフォームに登録されているアプリケーションに対して既定では発行されません。 アプリケーションの ID トークンを有効にするには、次のいずれかの方法を使用します。
- Microsoft Entra 管理センターにサインインします。
- ID>アプリケーション>アプリ登録><お使いのアプリケーション>>認証 を参照します。
- [プラットフォーム構成] で [プラットフォームを追加] を選択します。
- ウィンドウが開いたら、アプリケーションに最適なプラットフォームを選択します。 たとえば、Web アプリケーションに Web を選択します。
- [リダイレクト URI] で、アプリケーションのリダイレクト URI を追加します。 たとえば、
https://localhost:8080/
のようにします。 - [暗黙的な許可およびハイブリッド フロー] で、[ID トークン (暗黙的およびハイブリッド フローに使用)] チェックボックスをオンにします。
または:
- ID>アプリケーション>アプリの登録><アプリケーション>>マニフェスト を選択します。
- アプリ登録のアプリケーション マニフェストで、
oauth2AllowIdTokenImplicitFlow
をtrue
に設定します。
アプリに対して ID トークンが有効になっていない場合に、ID トークンが要求されると、Microsoft ID プラットフォームは次のような unsupported_response
エラーを返します。
The provided value for the input parameter 'response_type' isn't allowed for this client. (入力パラメーター 'response_type' に入力された値はこのクライアントで許可されません。) Expected value is 'code' (入力パラメーター 'response_type' に入力された値はこのクライアントで許可されません。入力できる値は 'code' です。) が返されます.
id_token
の response_type
を指定して ID トークンを要求することについて、この記事の後半の「サインイン要求を送信する」で説明します。
OpenID 構成ドキュメントを取得する
Microsoft ID プラットフォームなどの OpenID プロバイダーは、プロバイダーの OIDC エンドポイント、サポートされる要求、その他のメタデータを含むパブリック アクセス可能なエンドポイントで、OpenID プロバイダー構成ドキュメントを提供しています。 クライアント アプリケーションは、メタデータを使用して、認証に使用する URL や認証サービスの公開署名キーを検出できます。
認証ライブラリは、認証 URL、プロバイダーの公開署名キー、その他のサービス メタデータの検出に使用される OpenID 構成ドキュメントの最も一般的なコンシューマーです。 アプリで認証ライブラリを使用する場合、OpenID 構成ドキュメント エンドポイントに対する要求と応答を手動でコーディングする必要はほとんどの場合ありません。
アプリの OpenID 構成ドキュメント URI を見つける
Microsoft Entra ID でのすべてのアプリ登録で、OpenID 構成ドキュメントを提供するパブリック アクセス可能なエンドポイントが提供されます。 アプリの構成ドキュメントのエンドポイントの URI を確認するには、"既知の OpenID 構成" パスをアプリ登録の "機関 URL" に追加します。
- 既知の構成ドキュメント パス:
/.well-known/openid-configuration
- 機関 URL:
https://login.microsoftonline.com/{tenant}/v2.0
{tenant}
の値は、次の表に示されているように、アプリケーションのサインイン対象ユーザーによって異なります。 また、機関 URLは、クラウド インスタンスによっても異なります。
値 | 説明 |
---|---|
common |
個人の Microsoft アカウントを持つユーザーと Microsoft Entra ID の職場または学校アカウントを持つユーザーのどちらもアプリケーションにサインインできます。 |
organizations |
Microsoft Entra ID の職場/学校アカウントを持つユーザーのみがアプリケーションにサインインできます。 |
consumers |
個人の Microsoft アカウントを持つユーザーのみがアプリケーションにサインインできます。 |
Directory (tenant) ID または contoso.onmicrosoft.com |
特定の Microsoft Entra テナントのユーザー (職場または学校のアカウントを持つディレクトリ メンバー、または個人の Microsoft アカウントを持つディレクトリ ゲスト) のみ、アプリケーションにサインインできます。 値として、Microsoft Entra テナントのドメイン名、または GUID 形式のテナント ID を指定できます。 |
ヒント
個人の Microsoft アカウントに対して common
または consumers
機関を使用する場合は、signInAudience に従って、このような種類のアカウントをサポートするように消費リソース アプリケーションを構成する必要があることに注意してください。
Microsoft Entra管理センターで OIDC 構成ドキュメントを見つけるには、Microsoft Entra管理センター にサインインし、次の手順を実行します:
- ID>アプリケーション>アプリ登録><お使いのアプリケーション>>認証 を参照します。
- [OpenID Connect メタデータ ドキュメント] で URI を見つけます。
要求のサンプル
以下の要求では、Azure パブリック クラウド上の common
機関の OpenID 構成ドキュメント エンドポイントから OpenID 構成メタデータが取得されます。
GET /common/v2.0/.well-known/openid-configuration
Host: login.microsoftonline.com
ヒント
試してみる アプリケーションの common
機関の OpenID 構成ドキュメントを確認するには、https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration に移動します。
応答のサンプル
構成メタデータは、次の例に示すように JSON 形式で返されます (簡潔にするために一部省略しています)。 JSON 応答で返されるメタデータについて詳しくは、OpenID Connect 1.0 の検出の仕様に関するページを参照してください。
{
"authorization_endpoint": "https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize",
"token_endpoint": "https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token",
"token_endpoint_auth_methods_supported": [
"client_secret_post",
"private_key_jwt"
],
"jwks_uri": "https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys",
"userinfo_endpoint": "https://graph.microsoft.com/oidc/userinfo",
"subject_types_supported": [
"pairwise"
],
...
}
サインイン要求を送信する
ユーザーを認証し、アプリケーションで使用する ID トークンを要求するには、ユーザー エージェントが Microsoft ID プラットフォームの /authorize エンドポイントにアクセスするように指定します。 この要求は、OAuth 2.0 承認コード フローの最初の部分に似ていますが、次の点が異なります。
scope
パラメーターにopenid
スコープを含める。response_type
パラメーターでid_token
を指定する。nonce
パラメーターを含める。
サインイン要求の例 (読みやすくするために改行しています):
GET https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=id_token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=form_post
&scope=openid
&state=12345
&nonce=678910
パラメーター | Condition | 説明 |
---|---|---|
tenant |
必須 | 要求パスの {tenant} の値を使用して、アプリケーションにサインインできるユーザーを制御できます。 使用できる値は、common 、organizations 、consumers およびテナント識別子です。 詳細については、プロトコルの基本に関するセクションを参照してください。 重要なこととして、あるテナントから別のテナントにユーザーをサインインさせるゲスト シナリオでは、ユーザーをリソース テナントに正しくサインインさせるためにテナント識別子を指定する "必要があります"。 |
client_id |
必須 | [Microsoft Entra 管理センター - アプリの登録] エクスペリエンスからアプリに割り当てられたアプリケーション (クライアント) ID。 |
response_type |
必須 | OpenID Connect サインインでは、 id_token を指定する必要があります。 |
redirect_uri |
推奨 | アプリのリダイレクト URI。アプリは、この URI で認証応答を送受信することができます。 ポータルで登録したいずれかのリダイレクト URI と完全に一致させる必要があります (ただし、URL エンコードが必要)。 存在しない場合、エンドポイントでは登録されている redirect_uri がランダムに 1 つ選択され、ユーザーはそこに戻されます。 |
scope |
必須 | スコープのスペース区切りリスト。 OpenID Connect には、同意 UI のサインインアクセス許可に変換されるスコープopenid を含める必要があります。 同意を求めるこの要求には他のスコープが含まれていてもかまいません。 |
nonce |
必須 | ID トークンの要求でアプリによって生成され送信される値。 Microsoft ID プラットフォームによってアプリに返される ID トークンにも、同じ nonce 値が含まれます。 トークン再生攻撃を軽減するために、ID トークン内の nonce 値がトークンの要求時に送信された値と同じであることをアプリで確認する必要があります。 この値は、通常、ランダムな一意の文字列です。 |
response_mode |
推奨 | 結果として得られた承認コードをアプリに返す際に使用するメソッドを指定します。 form_post または fragment を指定できます。 Web アプリケーションでは、トークンをアプリケーションに最も安全に転送できるように、response_mode=form_post を使用することをお勧めします。 |
state |
推奨 | 要求に含まれ、トークンの応答としても返される値。 任意のコンテンツの文字列を指定することができます。 クロスサイト リクエスト フォージェリ攻撃を防ぐために通常、ランダムに生成された一意の値が使用されます。 この状態は、認証要求の前にアプリ内でユーザーの状態 (表示中のページやビューなど) に関する情報をエンコードする目的にも使用されます。 |
prompt |
省略可能 | ユーザーとの必要な対話の種類を指定します。 現時点で有効な値は、login 、none 、consent 、select_account のみです。 prompt=login 要求は、その要求においてユーザーに資格情報の入力を強制させ、シングル サインオンを無効にします。 prompt=none パラメーターは反対のものであり、 ユーザーがサインインする必要があることを示すために、login_hint と組み合わせて使用する必要があります。 これらのパラメーターは、ユーザーに対して対話形式のプロンプトをいっさい表示しません。 シングル サインオンで確認なしで要求を完了できない場合は、Microsoft ID プラットフォームからエラーが返されます。 原因は、サインインしているユーザーがいない、ヒントを表示するユーザーがサインインしていない、複数のユーザーがサインインしている一方で、ヒントが提供されなかった、などです。 prompt=consent 要求は、ユーザーがサインインした後に OAuth 同意ダイアログをトリガーします。 ダイアログでは、ユーザーにアプリへのアクセス許可を付与するよう要求します。 最後に、select_account がユーザーにアカウント セレクターを表示し、シングル サインアウトを無効にします。ただし、ユーザーは資格情報の入力を必要とせずに、サインインする意図のあるアカウントを選択できます。 login_hint と select_account はどちらも使用できません。 |
login_hint |
省略可能 | このパラメーターを使用すると、ユーザー名が事前にわかっている場合、ユーザーに代わって、サインイン ページのユーザー名とメール アドレスのフィールドに事前に入力することができます。 多くの場合、アプリは、以前のサインインから login_hint オプション クレームを抽出した後、認証時にこのパラメーターを使用します。 |
domain_hint |
省略可能 | フェデレーション ディレクトリ内のユーザーの領域。 これで、サインイン ページでユーザーが行う電子メール ベースの検出プロセスがスキップされ、ユーザー エクスペリエンスは若干簡素化されたものになります。 AD FS のようなオンプレミス ディレクトリを介してフェデレーションされているテナントの場合、この結果、既存のログイン セッションがあるためにシームレスなサインインになることがよくあります。 |
現時点では、ユーザーに資格情報の入力と認証が求められます。 Microsoft ID プラットフォームではまた、ユーザーが scope
クエリ パラメーターに示されたアクセス許可に同意していることが確認されます。 いずれのアクセス許可にもユーザーが同意しなかった場合、Microsoft ID プラットフォームに、必要なアクセス許可に同意するようユーザーに求めるプロンプトが表示されます。 詳細については、アクセス許可、同意、マルチテナント アプリに関する記事を参照してください。
ユーザーが認証され、同意すると、Microsoft ID プラットフォームは response_mode
パラメーターで指定されたメソッドを使用して、指定されたリダイレクト URI でアプリに応答を返します。
成功応答
response_mode=form_post
を使用した場合、成功応答は次のようになります。
POST /myapp/ HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNB...&state=12345
パラメーター | 説明 |
---|---|
id_token |
アプリが要求した ID トークン。 id_token パラメーターを使用してユーザーの本人性を確認し、そのユーザーとのセッションを開始することができます。 ID トークンとその内容について詳しくは、ID トークンのリファレンスを参照してください。 |
state |
要求に state パラメーターが含まれている場合、同じ値が応答にも含まれることになります。 要求と応答に含まれる状態値が同一であることをアプリ側で確認する必要があります。 |
エラー応答
アプリ側でエラーを処理できるように、リダイレクト URI にエラー応答が送信される場合もあります。次に例を示します。
POST /myapp/ HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
error=access_denied&error_description=the+user+canceled+the+authentication
パラメーター | 説明 |
---|---|
error |
発生したエラーの種類を分類したりエラーに対処したりする際に使用できるエラー コード文字列。 |
error_description |
認証エラーの根本的な原因を特定しやすいように記述した具体的なエラー メッセージ。 |
承認エンドポイント エラーのエラー コード
次の表で、エラー応答の error
パラメーターで返される可能性のあるエラー コードを説明します。
エラー コード | 説明 | クライアント側の処理 |
---|---|---|
invalid_request |
必要なパラメーターが不足しているなどのプロトコル エラーです。 | 要求を修正し再送信します。 この開発エラーは、アプリケーションのテスト時に見つける必要があります。 |
unauthorized_client |
クライアント アプリケーションは、承認コードを要求できません。 | このエラーは、クライアント アプリケーションが Microsoft Entra ID に登録されていない、またはユーザーの Microsoft Entra テナントに追加されていないときに発生する可能性があります。 アプリケーションでは、アプリケーションのインストールと Microsoft Entra ID への追加を求める指示をユーザーに表示できます。 |
access_denied |
リソースの所有者が同意を拒否しました。 | クライアント アプリケーションは、ユーザーが同意しないと続行できないことを、ユーザーに通知できます。 |
unsupported_response_type |
承認サーバーでは、要求に含まれる応答の種類がサポートされていません。 | 要求を修正し再送信します。 この開発エラーは、アプリケーションのテスト時に見つける必要があります。 |
server_error |
サーバーで予期しないエラーが発生しました。 | 要求をやり直してください。 これらのエラーは一時的な状況によって発生します。 クライアント アプリケーションは、一時的なエラーが原因で応答が遅れることをユーザーに説明する場合があります。 |
temporarily_unavailable |
サーバーが一時的にビジー状態であるため、要求を処理できません。 | 要求をやり直してください。 クライアント アプリケーションは、一時的な状況が原因で応答が遅れることをユーザーに説明する場合があります。 |
invalid_resource |
ターゲット リソースは、存在しない、Microsoft Entra ID で見つけられない、または正しく構成されていないために無効です。 | このエラーは、リソース (存在する場合) がテナントで構成されていないことを示します。 アプリケーションでは、アプリケーションのインストールと Microsoft Entra ID への追加を求める指示をユーザーに表示できます。 |
ID トークンの検証
アプリで ID トークンを受け取るだけでは、ユーザーを完全に認証できない場合があります。 場合により、アプリの要件に従って、ID トークンの署名を検証し、トークンの要求を確認する必要もあります。 すべての OpenID プロバイダーと同様に、Microsoft ID プラットフォームの ID トークンは、公開キー暗号化を使用して署名された JSON Web トークン (JWT) です。
承認に ID トークンを使用する Web アプリや Web API はデータにアクセスできるため、ID トークンを検証する必要があります。 ただし、その他の種類のアプリケーションでは、ID トークンの検証からメリットを得られない場合があります。 たとえば、ネイティブ アプリケーションとシングルページ アプリケーション (SPA) では、ID トークンの検証からメリットをほとんど得ることができません。これは、デバイスやブラウザーに物理的にアクセスするエンティティが、検証をバイパスする可能性があるためです。
トークン検証がバイパスされる 2 つの例を次に示します。
- デバイスへのネットワーク トラフィックを変更することで偽のトークンまたはキーを提供する
- アプリケーションをデバッグし、プログラムの実行中に検証ロジックをステップオーバーする。
アプリケーションで ID トークンを検証する場合、手動では "行わない" ことをお勧めします。 代わりに、トークン検証ライブラリを使用してトークンを解析および検証します。 トークン検証ライブラリは、ほとんどの開発言語、フレームワーク、プラットフォームで使用できます。
ID トークンで検証する内容
ID トークンの署名の検証に加えて、「ID トークンの検証」で説明されているように、トークンのいくつかの要求も検証する必要があります。 「署名キーのロールオーバーに関する重要な情報」も参照してください。
その他のいくつかの検証は一般的であり、次のようなアプリケーション シナリオによって異なります。
- ユーザー/組織がアプリにサインアップ済みであることを確認する。
- 適切な承認/特権がユーザーにあることを確認する。
- 多要素認証など特定の強度の認証が行われたことを確認する。
ID トークンを検証したら、ユーザーとのセッションを開始し、アプリの個人用設定、表示、またはデータの保存のために、トークンの要求内の情報を使用できます。
プロトコルのダイアグラム: アクセス トークンの取得
多くのアプリケーションでは、ユーザーをサインインさせるだけでなく、ユーザーの代わりに Web API などの保護されたリソースにアクセスする必要があります。 このシナリオでは、OpenID Connect でユーザーを認証するための ID トークンを取得することと、OAuth 2.0 で保護されたリソースのアクセス トークンを取得することを組み合わせます。
OpenID Connect によるサインインとトークン取得の完全なフローは、次の図のようになります。
UserInfo エンドポイントのアクセス トークンを取得する
ID トークンに加えて、認証されたユーザーの情報も OIDC の UserInfo エンドポイントで入手できます。
OIDC の UserInfo エンドポイントのアクセス トークンを取得するには、次に示されているようにサインイン要求を変更します。
// Line breaks are for legibility only.
GET https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444 // Your app registration's Application (client) ID
&response_type=id_token%20token // Requests both an ID token and access token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F // Your application's redirect URI (URL-encoded)
&response_mode=form_post // 'form_post' or 'fragment'
&scope=openid+profile+email // 'openid' is required; 'profile' and 'email' provide information in the UserInfo endpoint as they do in an ID token.
&state=12345 // Any value - provided by your app
&nonce=678910 // Any value - provided by your app
承認コード フロー、デバイス コード フローを使用して、または response_type=token
の代わりに更新トークンを使用して、アプリのアクセス トークンを取得できます。
正常なトークン応答
response_mode=form_post
を使用した場合の正常な応答を次に示します。
POST /myapp/ HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
access_token=eyJ0eXAiOiJKV1QiLCJub25jZSI6I....
&token_type=Bearer
&expires_in=3598
&scope=email+openid+profile
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI....
&state=12345
応答パラメーターは、その取得に使用されたフローに関係なく、同じことを意味します。
パラメーター | 説明 |
---|---|
access_token |
UserInfo エンドポイントを呼び出すために使用されるトークン。 |
token_type |
常に "Bearer" です |
expires_in |
アクセス トークンの有効期限が切れるまでの時間 (秒単位)。 |
scope |
アクセス トークンに付与されるアクセス許可。 UserInfo エンドポイントは Microsoft Graph でホストされるため、scope には、アプリケーションに以前付与された他のもの (たとえば、User.Read ) を含めることができます。 |
id_token |
アプリが要求した ID トークン。 この ID トークンを使用してユーザーの本人性を確認し、そのユーザーとのセッションを開始することができます。 ID トークンとその内容について詳しくは、ID トークンのリファレンスを参照してください。 |
state |
要求に state パラメーターが含まれている場合、同じ値が応答にも含まれることになります。 要求と応答に含まれる状態値が同一であることをアプリ側で確認する必要があります。 |
警告
この例のトークンを含めて、自分が所有していないすべての API について、トークンの検証や読み取りを行わないでください。 Microsoft サービスのトークンには、JWT として検証されない特殊な形式を使用できます。また、コンシューマー (Microsoft アカウント) ユーザーに対して暗号化される場合もあります。 トークンの読み取りは便利なデバッグおよび学習ツールですが、コード内でこれに対する依存関係を取得したり、自分で制御する API 用ではないトークンについての詳細を想定したりしないでください。
エラー応答
アプリ側でエラーを適切に処理できるように、リダイレクト URI にエラー応答が送信される場合もあります。
POST /myapp/ HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
error=access_denied&error_description=the+user+canceled+the+authentication
パラメーター | 説明 |
---|---|
error |
発生したエラーの種類を分類したりエラーに対処したりする際に使用できるエラー コード文字列。 |
error_description |
認証エラーの根本的な原因を特定しやすいように記述した具体的なエラー メッセージ。 |
想定されるエラー コードと推奨されるクライアントの応答については、「承認エンドポイント エラーのエラー コード」を参照してください。
承認コードと ID トークンがある場合は、ユーザーをサインインさせ、代わりにアクセス トークンを取得できます。 ユーザーをサインインさせるには、トークンの検証に関するセクションに説明されているとおりに ID トークンを検証する必要があります。 アクセス トークンを取得するには、OAuth コード フローのドキュメントに記載されている手順に従って取得できます。
UserInfo エンドポイントを呼び出す
UserInfo ドキュメントを確認し、このトークンで UserInfo エンドポイントを呼び出す方法を参照してください。
サインアウト要求を送信する
ユーザーをサインアウトするには、次の両方の操作を実行します。
- ユーザーのユーザー エージェントを Microsoft ID プラットフォームのログアウト URI にリダイレクトします。
- アプリの Cookie をクリアするか、アプリケーションでユーザーのセッションを終了します。
これらの操作のいずれかを実行しなかった場合、ユーザーは認証されたままになり、次回アプリを使用するときにサインインするように求められない場合があります。
OpenID Connect 構成ドキュメントに示されているように、ユーザー エージェントを end_session_endpoint
にリダイレクトします。 end_session_endpoint
は、HTTP の GET 要求と POST 要求の両方をサポートしています。
GET https://login.microsoftonline.com/common/oauth2/v2.0/logout?
post_logout_redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
パラメーター | Condition | 説明 |
---|---|---|
post_logout_redirect_uri |
推奨 | サインアウトの正常終了後にユーザーをリダイレクトする URL。このパラメーターを含めない場合、Microsoft ID プラットフォームによって生成された汎用メッセージがユーザーに表示されます。 この URL は、アプリ登録ポータルのアプリケーションに対する登録済みリダイレクト URI のいずれかと一致させる必要があります。 |
logout_hint |
省略可能 | ユーザーにアカウントの選択を求めるプロンプトを出さずに、サインアウトを実行できるようにします。 logout_hint を使用するには、クライアント アプリケーションでオプションのクレーム login_hint を有効にし、logout_hint パラメーターとしてオプションのクレーム login_hint の値を使用します。 logout_hint パラメーターの値として UPN や電話番号は使用しないでください。 |
Note
サインアウトが成功すると、アクティブなセッションは非アクティブに設定されます。 サインアウトしたユーザーに対する有効なプライマリ更新トークン (PRT) が存在している場合に、新しいサインインが実行されると、シングル サインアウトは中断され、アカウント ピッカーを含むプロンプトがユーザーに表示されます。 PRT を参照する接続されているアカウントのオプションを選んだ場合、新しい資格情報を挿入しなくてもサインインは自動的に続けられます。
シングル サインアウト
ユーザーをアプリケーションの end_session_endpoint
にリダイレクトすると、Microsoft ID プラットフォームはこのアプリケーションのユーザー セッションを終了します。 ただし、ユーザーは認証に同じ Microsoft アカウントを使用する他のアプリケーションにサインインしたままになることがあります。
ユーザーがこのディレクトリ (テナントとも呼ばれます) に登録されている複数の Web または SPA アプリケーションにサインインしている場合、このユーザーがアプリケーションのいずれかでサインアウトすると、シングル サインアウト により、すべてのアプリケーションから即時にサインアウトできます。
Entra アプリケーションのシングル サインアウトを有効にするには、OpenID Connect フロント チャネル ログアウト機能を使用する必要があります。 この機能を使用すると、アプリケーションはユーザーがログアウトしたことを他のアプリケーションに通知できます。ユーザーが 1 つのアプリケーションからログアウトすると、Microsoft ID プラットフォームは、ユーザーが現在サインインしているすべてのアプリケーションのフロント チャネル ログアウト URL に HTTP GET 要求を送信します。
これらのアプリケーションは、シングル サインアウトを成功させるために次の 2 つのアクションを実行して、この要求に応答する必要があります。
- ユーザーを識別するセッションをクリアします。
- アプリケーションは、ユーザーを識別するすべてのセッションを消去し、
200
応答を返すことで、この要求に応答する必要があります。
フロント チャネル ログアウト URL とは何ですか?
フロント チャネル ログアウト URL は、Web または SPA アプリケーションが Entra 認証サーバーからサインアウト要求を受信し、シングル サインアウト機能を実行する場所です。 各アプリケーションには 1 つのフロント チャネル ログアウト URL があります。
フロント チャネル ログアウト URL はいつ設定する必要がありますか?
ユーザーまたは開発者がアプリケーションにシングル サインアウトが必要であると判断した場合は、このアプリケーションのアプリ登録のフロント チャネル ログアウト URL を設定する必要があります。 このアプリケーションのアプリ登録に対してフロント チャネル ログアウト URL が設定されると、Microsoft ID プラットフォームは、サインインしているユーザーが別のアプリケーションからサインアウトしたときに、このアプリケーションのフロント チャネル ログアウト URL に HTTP GET 要求を送信します。
フロント チャネル ログアウト機能を使用してシングル サインアウトを設定する方法
一連のアプリケーションでフロント チャネル ログアウト機能を使用するには、次の 2 つのタスクを完了する必要があります。
- 同時にサインアウトする必要があるすべてのアプリケーションについて、Microsoft Entra 管理センターでフロント チャネル ログアウト URL を設定します。 通常、各アプリケーションには独自の専用フロント チャネル ログアウト URL があります。
- アプリケーション コードを編集して、Microsoft ID プラットフォームからフロント チャネル ログアウト URL に送信された HTTP GET 要求をリッスンし、ユーザーを識別するセッションをクリアして 200 応答を返すことで、この要求に応答します。
フロント チャネル ログアウト URL を選択する方法
フロント チャネル ログアウト URL は、HTTP GET 要求を受信して応答できる URL であり、ユーザーを識別するセッションをクリアできる必要があります。 フロント チャネル ログアウト URL の例としては、次のような場合があります。ただし、これらに限定されるわけではありません。
次のステップ
- UserInfo エンドポイントのドキュメントを確認する。
- オンプレミス システムからのデータを、トークン内の要求値に設定する。
- トークンに独自の要求を含める.