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 の基本的なサインイン フローを示しています。 フローの手順については、記事の後半のセクションで詳しく説明します。

OpenID Connect プロトコルのサインイン フローを示すスイムレーン図。

ヒント

Postman でこの要求を実行してみる
Postman でこの要求やその他を実行してみてください。その際、トークンと ID を忘れずに置き換えてください。

ID トークンを有効にする

OpenID Connect によって導入された "ID トークン" は、クライアント アプリケーションがユーザー認証中に ID トークンを要求したときに、承認サーバー (Microsoft ID プラットフォーム) によって発行されます。 ID トークンによって、クライアント アプリケーションはユーザーが本人であることを確認でき、そのユーザーに関するその他の情報 (要求) を取得できます。

ID トークンは、Microsoft ID プラットフォームに登録されているアプリケーションに対して既定では発行されません。 次のいずれかの方法を使用して、アプリに対して ID トークンを有効にします。

アプリに対して ID トークンを有効にするには、Azure portal に移動し、次の操作を行います。

  1. [Azure Active Directory]>[アプリの登録]> "<自分のアプリケーション>" >[認証] を選択します。
  2. [暗黙的な許可およびハイブリッド フロー] で、[ID トークン (暗黙的およびハイブリッド フローに使用)] チェックボックスをオンにします。

または:

  1. [Azure Active Directory]>[アプリの登録]> "<自分のアプリケーション>" >[マニフェスト] を選択します。
  2. アプリ登録のアプリケーション マニフェストで、oauth2AllowIdTokenImplicitFlowtrue に設定します。

アプリに対して 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'. (入力できる値は 'code' です。)

id_tokenresponse_type を指定して ID トークンを要求することについて、この記事の後半の「サインイン要求を送信する」で説明します。

OpenID 構成ドキュメントを取得する

Microsoft ID プラットフォームなどの OpenID プロバイダーは、プロバイダーの OIDC エンドポイント、サポートされる要求、その他のメタデータを含むパブリック アクセス可能なエンドポイントで、OpenID プロバイダー構成ドキュメントを提供しています。 クライアント アプリケーションは、メタデータを使用して、認証に使用する URL や認証サービスの公開署名キーを特に検出できます。

認証ライブラリは、認証 URL、プロバイダーの公開署名キー、その他のサービス メタデータの検出に使用される OpenID 構成ドキュメントの最も一般的なコンシューマーです。 アプリで認証ライブラリを使用する場合 (推奨)、OpenID 構成ドキュメント エンドポイントに対する要求と応答を手動でコーディングする必要はほとんどの場合ありません。

アプリの OpenID 構成ドキュメント URI を見つける

Azure AD でのすべてのアプリ登録で、OpenID 構成ドキュメントを提供するパブリック アクセス可能なエンドポイントが提供されます。 アプリの構成ドキュメントのエンドポイントの URI を確認するには、"既知の OpenID 構成" パスをアプリ登録の "機関 URL" に追加します。

  • 既知の構成ドキュメント パス: /.well-known/openid-configuration
  • 機関 URL: https://login.microsoftonline.com/{tenant}/v2.0

{tenant} の値は、次の表に示されているように、アプリケーションのサインイン対象ユーザーによって異なります。 また、機関 URLは、クラウド インスタンスによっても異なります。

説明
common 個人の Microsoft アカウントを持つユーザーと Azure AD の職場/学校アカウントを持つユーザーのどちらもアプリケーションにサインインできます。
organizations Azure AD の職場/学校アカウントを持つユーザーのみがアプリケーションにサインインできます。
consumers 個人の Microsoft アカウントを持つユーザーのみがアプリケーションにサインインできます。
8eaef023-2b34-4da1-9baa-8bc8c9d6a490 または contoso.onmicrosoft.com 特定の Azure AD テナントのユーザー (職場または学校のアカウントを持つディレクトリ メンバー、または個人の Microsoft アカウントを持つディレクトリ ゲスト) のみ、アプリケーションにサインインできます。

値として、Azure AD テナントのドメイン名、または GUID 形式のテナント ID を指定できます。 consumers の代わりに、コンシューマー テナント GUID である 9188040d-6c67-4c5b-b112-36a304b66dad を使用することもできます。

ヒント

個人の Microsoft アカウントに対して common または consumers 機関を使用する場合は、signInAudience に従って、このような種類のアカウントをサポートするように消費リソース アプリケーションを構成する必要があることに注意してください。

アプリの OpenID 構成ドキュメント URI は、Azure portal のアプリ登録でも見つけることができます。

アプリの OIDC 構成ドキュメントを見つけるには、Azure portal に移動し、次の操作を行います。

  1. [Azure Active Directory]>[アプリの登録]> "<自分のアプリケーション>" >[エンドポイント] を選択します。
  2. [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 または code+id_token を指定する。
  • nonce パラメーターを含める。

サインイン要求の例 (読みやすくするために改行しています):

GET https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=id_token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=form_post
&scope=openid
&state=12345
&nonce=678910
パラメーター 条件 説明
tenant 必須 要求パスの {tenant} の値を使用して、アプリケーションにサインインできるユーザーを制御できます。 使用できる値は、commonorganizationsconsumers およびテナント識別子です。 詳細については、プロトコルの基本に関するセクションを参照してください。 重要なこととして、あるテナントから別のテナントにユーザーをサインインさせるゲスト シナリオでは、ユーザーをリソース テナントに正しくサインインさせるためにテナント識別子を指定する "必要があります"。
client_id 必須 Azure portal の [アプリの登録] エクスペリエンスでアプリに割り当てられたアプリケーション (クライアント) ID
response_type 必須 OpenID Connect サインインでは、 id_token を指定する必要があります。 code などの他の response_type の値が含まれる場合もあります。
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 省略可能 ユーザーとの必要な対話の種類を指定します。 現時点で有効な値は、loginnoneconsentselect_account のみです。 prompt=login 要求は、その要求においてユーザーに資格情報の入力を強制させ、シングル サインオンを無効にします。 prompt=none パラメーターは反対のものであり、 ユーザーがサインインする必要があることを示すために、login_hint と組み合わせて使用する必要があります。 これらのパラメーターは、ユーザーに対して対話形式のプロンプトをいっさい表示しません。 シングル サインオンで確認なしで要求を完了できない場合は、Microsoft ID プラットフォームからエラーが返されます。 原因は、サインインしているユーザーがいない、ヒントを表示するユーザーがサインインしていない、複数のユーザーがサインインしている一方で、ヒントが提供されなかった、などです。 prompt=consent 要求は、ユーザーがサインインした後に OAuth 同意ダイアログをトリガーします。 ダイアログでは、ユーザーにアプリへのアクセス許可を付与するよう要求します。 最後に、select_account がユーザーにアカウント セレクターを表示し、サイレント SSO を否定します。ただし、ユーザーは資格情報の入力を要求することなく、サインインする意図のあるアカウントを選択できます。 login_hintselect_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 クライアント アプリケーションは、承認コードを要求できません。 このエラーは、クライアント アプリケーションが Azure AD に登録されていない、またはユーザーの Azure AD テナントに追加されていないときに発生する可能性があります。 アプリケーションでは、アプリケーションのインストールと Azure AD への追加を求める指示をユーザーに表示できます。
access_denied リソースの所有者が同意を拒否しました。 クライアント アプリケーションは、ユーザーが同意しないと続行できないことを、ユーザーに通知できます。
unsupported_response_type 承認サーバーでは、要求に含まれる応答の種類がサポートされていません。 要求を修正し再送信します。 この開発エラーは、アプリケーションのテスト時に見つける必要があります。
server_error サーバーで予期しないエラーが発生しました。 要求をやり直してください。 これらのエラーは一時的な状況によって発生します。 クライアント アプリケーションは、一時的なエラーが原因で応答が遅れることをユーザーに説明する場合があります。
temporarily_unavailable サーバーが一時的にビジー状態であるため、要求を処理できません。 要求をやり直してください。 クライアント アプリケーションは、一時的な状況が原因で応答が遅れることをユーザーに説明する場合があります。
invalid_resource 対象のリソースは、存在しない、Azure AD で見つけられない、または正しく構成されていないために無効です。 このエラーは、リソース (存在する場合) がテナントで構成されていないことを示します。 アプリケーションでは、アプリケーションのインストールと Azure AD への追加を求める指示をユーザーに表示できます。

ID トークンの検証

アプリで ID トークンを受け取るだけでは、ユーザーを完全に認証できない場合があります。 場合により、アプリの要件に従って、ID トークンの署名を検証し、トークンの要求を確認する必要もあります。 すべての OpenID プロバイダーと同様に、Microsoft ID プラットフォームの ID トークンは、公開キー暗号化を使用して署名された JSON Web トークン (JWT) です。

承認に ID トークンを使用する Web アプリと Web API では、ID トークンを検証する必要があります。これは、このようなアプリケーションでは、データへのアクセスを制限するためです。 ただし、その他の種類のアプリケーションでは、ID トークンの検証からメリットを得られない場合があります。 たとえば、ネイティブ アプリとシングルページ アプリ (SPA) では、ID トークンの検証からメリットをほとんど得ることができません。これは、デバイスやブラウザーに物理的にアクセスするエンティティが、検証をバイパスする可能性があるためです。

トークン検証がバイパスされる 2 つの例を次に示します。

  • デバイスへのネットワーク トラフィックを変更することで偽のトークンまたはキーを提供する
  • アプリケーションをデバッグし、プログラムの実行中に検証ロジックをステップオーバーする。

アプリケーションで ID トークンを検証する場合、手動では "行わない" ことをお勧めします。 代わりに、トークン検証ライブラリを使用してトークンを解析および検証します。 トークン検証ライブラリは、ほとんどの開発言語、フレームワーク、プラットフォームで使用できます。

ID トークンで検証する内容

ID トークンの署名の検証に加えて、ID トークンのリファレンスの「ID トークンの検証」で説明されているように、トークンのいくつかの要求も検証する必要があります。 「署名キーのロールオーバーに関する重要な情報」も参照してください。

その他のいくつかの検証は一般的であり、次のようなアプリケーション シナリオによって異なります。

  • ユーザー/組織がアプリにサインアップ済みであることを確認する。
  • 適切な承認/特権がユーザーにあることを確認する。
  • 多要素認証など特定の強度の認証が行われたことを確認する。

ID トークンを検証したら、ユーザーとのセッションを開始し、アプリの個人用設定、表示、またはデータの保存のために、トークンの要求内の情報を使用できます。

プロトコルのダイアグラム: アクセス トークンの取得

多くのアプリケーションでは、ユーザーをサインインさせるだけでなく、ユーザーの代わりに Web API などの保護されたリソースにアクセスする必要があります。 このシナリオでは、OpenID Connect でユーザーを認証するための ID トークンを取得することと、OAuth 2.0 で保護されたリソースのアクセス トークンを取得することを組み合わせます。

OpenID Connect によるサインインとトークン取得の完全なフローは、次の図のようになります。

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=6731de76-14a6-49ae-97bc-6eba6914391e        // 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
パラメーター 条件 説明
post_logout_redirect_uri 推奨 サインアウトの正常終了後にユーザーをリダイレクトする URL。このパラメーターを含めない場合、Microsoft ID プラットフォームによって生成された汎用メッセージがユーザーに表示されます。 この URL は、アプリ登録ポータルのアプリケーションに対する登録済みリダイレクト URI のいずれかと一致させる必要があります。
logout_hint オプション ユーザーにアカウントの選択を求めるプロンプトを出さずに、サインアウトを実行できるようにします。 logout_hint を使用するには、クライアント アプリケーションで省略可能な要求login_hint を有効にし、logout_hint パラメーターとして省略可能な要求 login_hint の値を使用します。 logout_hint パラメーターの値として UPN や電話番号は使用しないでください。

Note

サインアウトが成功すると、アクティブなセッションは非アクティブに設定されます。 サインアウトしたユーザーに対する有効なプライマリ更新トークン (PRT) が存在している場合に、新しいサインインが実行されると、SSO は中断され、アカウント ピッカーを含むプロンプトがユーザーに表示されます。 PRT を参照する接続されているアカウントのオプションを選んだ場合、新しい資格情報を挿入しなくてもサインインは自動的に続けられます。

シングル サインアウト

ユーザーが end_session_endpoint にリダイレクトされると、Microsoft ID プラットフォームによって、ユーザーのセッションがブラウザーから消去されます。 ただし、ユーザーは認証に Microsoft アカウントを使用する他のアプリケーションにサインインしたままになることがあります。 ユーザーがアプリケーションから同時にサインアウトできるように、Microsoft ID プラットフォームからユーザーが現在サインインしているすべてのアプリケーションの登録済み LogoutUrl に HTTP GET 要求が送信されます。 アプリケーションは、ユーザーを識別するすべてのセッションを消去し、200 応答を返すことで、この要求に応答する必要があります。 アプリケーションでシングル サインアウトをサポートする場合は、アプリケーションのコードで LogoutUrl などを実装する必要があります。 LogoutUrl は、アプリ登録ポータルから設定できます。

次のステップ