Azure Active Directory B2C でセッションの動作を構成する

[アーティクル]
11/20/2023

開始する前に、[ポリシーの種類の選択] セレクターを使用して、設定するポリシーの種類を選択します。 Azure Active Directory B2C には、ユーザーがアプリケーションを操作する方法を定義する 2 つの方法 (定義済みのユーザーフローを使用する、または完全に構成可能なカスタムポリシーを使用する) があります。この記事で必要な手順は、方法ごとに異なります。

シングルサインオン (SSO) によって、ユーザーが Azure Active Directory B2C (Azure AD B2C) のアプリケーションにサインインするときのセキュリティと利便性が向上します。この記事では、Azure AD B2C で使用されるシングルサインオンの方法について説明します。ポリシーを構成するときに最適な SSO 方法を選択するのに役立ちます。

シングルサインオンを使用すると、ユーザーは 1 つのアカウントで 1 回サインインするだけで、複数のアプリケーションにアクセスできます。アプリケーションは、Web、モバイル、シングルページのどのアプリケーションでもよく、プラットフォームまたはドメイン名には関係ありません。

ユーザーが初めてアプリケーションにサインインしたときに、Azure AD B2C によって Cookie ベースのセッションが保持されます。それ以降の認証要求では、Azure AD B2C によって Cookie ベースのセッションが読み取られて検証され、アクセストークンが発行されます。ユーザーにサインインを求めるメッセージが再び表示されることはありません。 Cookie ベースのセッションが有効期限切れまたは無効になった場合、ユーザーはもう一度サインインするように求められます。

前提条件

ユーザーフローを作成して、ユーザーがアプリケーションにサインアップおよびサインインできるようにします。
Web アプリケーションを登録します。

「Active Directory B2C でのカスタムポリシーの概要」にある手順を完了します。
Web アプリケーションを登録します。

Azure AD B2C セッションの概要

Azure AD B2C との統合には、次の 3 種類の SSO セッションが含まれます。

Azure AD B2C - Azure AD B2C によって管理されるセッション
フェデレーション ID プロバイダー - ID プロバイダー (Facebook、Salesforce、Microsoft アカウントなど) によって管理されるセッション
アプリケーション - Web アプリケーション、モバイルアプリケーション、またはシングルページアプリケーションによって管理されるセッション

SSO session

Azure AD B2C のセッション

ユーザーがローカルアカウントまたはソーシャルアカウントでの認証に成功すると、Azure AD B2C によって Cookie ベースのセッションがユーザーのブラウザーに保存されます。 Cookie は、Azure AD B2C テナントのドメイン名 (https://contoso.b2clogin.com など) の下に格納されます。

ユーザーがフェデレーションアカウントでサインインすると、セッションの時間枠 (Time to Live (TTL) とも呼ばれます) が開始されます。ユーザーがこの TTL 内で同じアプリまたは別のアプリにサインインすると、Azure AD B2C はフェデレーション ID プロバイダーから新しいアクセストークンを取得しようとします。フェデレーション ID プロバイダーセッションが有効期限切れまたは無効になった場合、ユーザーはフェデレーション ID プロバイダーから資格情報の入力を求められます。ユーザーのセッションが継続している場合、またはユーザーがフェデレーションアカウントではなくローカルアカウントを使用してサインインしている場合は、Azure AD B2C によってユーザーが承認され、それ以上のプロンプトは表示されません。

セッションの TTL や、Azure AD B2C によりポリシーやアプリケーション間でセッションが共有される方法など、セッションの動作を構成できます。

フェデレーション ID プロバイダーセッション

ソーシャルまたはエンタープライズ ID プロバイダーにより、独自のセッションが管理されます。 Cookie は、ID プロバイダーのドメイン名 (https://login.salesforce.com など) の下に格納されます。 Azure AD B2C では、フェデレーション ID プロバイダーのセッションは制御されません。代わりに、セッションの動作はフェデレーション ID プロバイダーによって決定されます。

以下のシナリオについて考えてみます。

ユーザーが Facebook にサインインして、フィードを確認します。
その後、ユーザーがアプリケーションを開き、サインインプロセスを開始します。アプリケーションでは、ユーザーを Azure AD B2C にリダイレクトして、サインインプロセスを完了します。
Azure AD B2C のサインアップページまたはサインインページで、ユーザーは Facebook アカウントでのサインインを選択します。ユーザーは Facebook にリダイレクトされます。 Facebook にアクティブなセッションがある場合、ユーザーは資格情報の入力を求められることはなく、Facebook のトークンを使用して Azure AD B2C に直ちにリダイレクトされます。

アプリケーションセッション

Web、モバイル、または単一ページアプリケーションは、OAuth2 アクセストークン、ID トークン、または SAML トークンによって保護できます。ユーザーがアプリの保護されたリソースにアクセスしようとすると、アプリケーション側にアクティブなセッションがあるかどうかが、アプリによって確認されます。アプリセッションが存在しないか、セッションの有効期限が切れた場合、アプリはユーザーを Azure AD B2C サインインページに誘導します。

アプリケーションのセッションは、アプリケーションドメイン名 (https://contoso.com など) の下に格納されている Cookie ベースのセッションでもかまいません。モバイルアプリケーションでは、セッションの格納方法が異なる場合がありますが、同様のアプローチが使用されます。

Azure AD B2C セッションの動作を構成する

次のような Azure AD B2C セッションの動作を構成できます。

[Web アプリのセッションの有効期間 (分)] - 認証が成功した後で、ユーザーのブラウザーに Azure AD B2C セッション Cookie が格納されている時間の長さです。セッションの有効期間は最大 24 時間まで設定できます。
[Web アプリのセッションタイムアウト] - セッションの有効期間の設定または "サインインしたままにする" (KMSI) 設定によってセッションがどのように拡張されるかが示されます。
- [ローリング] - ユーザーが Cookie ベースの認証 (既定) を実行するたびにセッションが延長されることを示します。
- [絶対] - 指定した時間が経過した後、再認証がユーザーに強制されることを示します。
[シングルサインオン構成] - Azure AD B2C のセッションは、次のスコープで構成できます。
- [テナント] - この設定が既定値です。この設定を使用すると、B2C テナント内の複数のアプリケーションとユーザーフローで同じユーザーセッションを共有できます。たとえば、ユーザーがあるアプリケーションにサインインすると、そのユーザーは別のアプリケーションにもシームレスにサインインしてアクセスできます。
- [アプリケーション] - この設定により、ユーザーセッションをあるアプリケーションに対して、他のアプリケーションとは独立に排他的に維持できます。たとえば、ユーザーが Contoso Groceries に既にサインインしているかどうかに関係なく、Contoso Pharmacy にサインインできるようにする場合は、この設定を使用できます。
- [ポリシー] - この設定により、ユーザーセッションをあるポリシーに対して、そのユーザーフローを使用するアプリケーションとは独立に排他的に維持できます。たとえば、Azure AD B2C は、ユーザーが既にサインインし、多要素認証 (MFA) の手順を完了している場合、複数のアプリケーションのセキュリティの高い部分へのアクセス権をユーザーに付与します。このアクセスは、ユーザーフローに関連付けられているセッションがアクティブなままである限り続行されます。
- [抑制] - この設定は、ユーザーフローを実行するたびに、ユーザーにユーザー体験全体を強制的に実行させます。

ユーザーフローを構成する

ユーザーフローでセッション動作を構成するには、次の手順に従います。

Azure portal にサインインします。
複数のテナントにアクセスできる場合、上部のメニューの [設定] アイコンを選択し、[ディレクトリとサブスクリプション] メニューからお使いの Azure AD B2C テナントに切り替えます。
Azure portal の左上隅にある [すべてのサービス] を選択してから、 [Azure AD B2C] を検索して選択します。
[ユーザーフロー] を選択します。
あらかじめ作成しておいたユーザーフローを開きます。
[プロパティ] を選択します。
[Web アプリのセッションの有効期間 (分)] 、 [Web アプリのセッションタイムアウト] 、 [シングルサインオン構成] 、 [ログアウト要求に ID トークンが必要] を必要に応じて構成します。
[保存] をクリックします。

カスタムポリシーを構成する

カスタムポリシーでセッション動作を構成するには、次の手順に従います。

証明書利用者 (RP) ファイルを開きます (例: SignUpOrSignin.xml)。

まだ存在しない場合は、<RelyingParty> 要素に次の要素 <UserJourneyBehaviors> を追加します。 <DefaultUserJourney ReferenceId="UserJourney Id"/> の直後に配置する必要があります。

<UserJourneyBehaviors>
  <SingleSignOn Scope="Application" />
  <SessionExpiryType>Absolute</SessionExpiryType>
  <SessionExpiryInSeconds>86400</SessionExpiryInSeconds>
</UserJourneyBehaviors>

ユーザー体験の動作要素を追加すると、RelyingParty 要素は次の例のようになります。

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <UserJourneyBehaviors>
    <SingleSignOn Scope="Application" />
    <SessionExpiryType>Absolute</SessionExpiryType>
    <SessionExpiryInSeconds>86400</SessionExpiryInSeconds>
  </UserJourneyBehaviors>
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="displayName" />
      <OutputClaim ClaimTypeReferenceId="givenName" />
      ...
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

Scope 属性の値を、Suppressed、Tenant、Application、または Policy のいずれかの値に変更します。詳細については、RelyingParty のリファレンス記事を参照してください。
SessionExpiryType 要素を Rolling または Absolute に設定します。詳細については、RelyingParty のリファレンス記事を参照してください。
SessionExpiryInSeconds 要素を 900 秒 (15 分) から 86,400 秒 (24 時間) の間の数値に設定します。詳細については、RelyingParty のリファレンス記事を参照してください。

"サインインしたままにする (KMSI)" を有効にする

KMSI 機能は、Azure AD B2C ディレクトリでローカルアカウントを持つ Web 利用ユーザーとネイティブアプリケーションに対して有効にできます。この機能を有効にし、ユーザーがサインインしたままにすることを選択すると、ブラウザーを閉じた後もセッションのアクティブ状態が続きます。永続 Cookie を設定することによって、セッションが維持されます。 KMSI を選択したユーザーがブラウザーを再度開いても、ユーザー名とパスワードの再入力は求められません。このアクセス (永続的な Cookie) は、ユーザーがサインアウトすると取り消されます。詳細については、ライブデモを参照してください。

Example sign-up sign-in page showing a Keep me signed in checkbox

KMSI は、個々のユーザーフローレベルで構成できます。ユーザーフローに対して KMSI を有効にする前に、次の点を考慮してください。

KMSI は、推奨バージョンのサインアップ/サインイン (SUSI)、サインイン、およびプロファイル編集ユーザーフローに対してのみサポートされています。現在、標準 (レガシ) またはレガシプレビュー (v2) バージョンのユーザーフローを使用しており、この状況で KMSI を有効にするには、これらのユーザーフローの推奨バージョンを新たに作成する必要があります。
KMSI は、パスワードリセットフローまたはサインアップユーザーフローではサポートされていません。
テナント内のすべてのアプリケーションに対して KMSI を有効にする場合は、テナント内のすべてのユーザーフローに対して KMSI を有効にすることをお勧めします。セッション中に複数のポリシーがユーザーに提示され、KMSI が有効になっていないユーザーが、セッションから KMSI Cookie を削除する可能性があるためです。
公共のコンピューターで KMSI を有効にすることはできません。

ユーザーフロー用に KMSI を構成する

ユーザーフローで KMSI を有効にするには、次の手順を実行します。

Azure portal にサインインします。
複数のテナントにアクセスできる場合、上部のメニューの [設定] アイコンを選択し、[ディレクトリとサブスクリプション] メニューからお使いの Azure AD B2C テナントに切り替えます。
Azure portal の左上隅にある [すべてのサービス] を選択してから、 [Azure AD B2C] を検索して選択します。
[ユーザーフロー (ポリシー)] を選択します。
あらかじめ作成しておいたユーザーフローを開きます。
[プロパティ] を選択します。
[セッションの動作] で [[セッションにサインインしたままにする] を有効にする] を選択します。 [セッションにサインインしたままにする (日数)] の横に、1 から 90 までの値を入力して、セッションを開いたままにする日数を指定します。

公共のコンピューターではこのオプションを有効にしないでください。

ページ識別子を設定する

KMSI を有効にするには、コンテンツ定義の DataUri 要素をページ IDunifiedssp に設定し、ページバージョンを 1.1.0 以上に設定します。

ポリシーの拡張ファイルを開きます。たとえば、SocialAndLocalAccounts/TrustFrameworkExtensions.xml のようにします。この拡張ファイルは、カスタムポリシースターターパックに含まれているポリシーファイルの 1 つであり、カスタムポリシーの概要に関するページの前提条件の中で、取得済みになっている必要があります。
BuildingBlocks 要素を検索します。要素が存在しない場合は追加します。

ContentDefinitions 要素をポリシーの BuildingBlocks 要素に追加します。

カスタムポリシーは次のコードスニペットのようになります。

<BuildingBlocks>
  <ContentDefinitions>
    <ContentDefinition Id="api.signuporsignin">
      <DataUri>urn:com:microsoft:aad:b2c:elements:unifiedssp:1.1.0</DataUri>
    </ContentDefinition>
  </ContentDefinitions>
</BuildingBlocks>

メタデータをセルフアサート技術プロファイルに追加する

サインアップおよびサインインページに KMSI チェックボックスを追加するには、setting.enableRememberMe メタデータを [true] に設定します。拡張ファイルで SelfAsserted-LocalAccountSignin-Email 技術プロファイルを上書きします。

ClaimsProviders 要素を見つけます。要素が存在しない場合は追加します。

ClaimsProviders 要素に次のクレームプロバイダーを追加します。

<ClaimsProvider>
  <DisplayName>Local Account</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
      <Metadata>
        <Item Key="setting.enableRememberMe">True</Item>
      </Metadata>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

拡張ファイルを保存します。

証明書利用者ファイルを設定する

作成したユーザー体験を開始する証明書利用者 (RP) ファイルを更新します。 keepAliveInDays パラメーターを使用すると、サインインしたままにする (KMSI) セッションの Cookie を保持する期間を構成できます。たとえば、値を 30 に設定した場合、KMSI セッションの Cookie は 30 日間保持されます。値の範囲は 1 日から 90 日です。値を 0 に設定すると、KMSI 機能がオフになります。

カスタムポリシーファイルを開きます。たとえば、SignUpOrSignin.xml などです。
まだ存在しない場合は、子ノード <UserJourneyBehaviors> を <RelyingParty> ノードに追加します。 <DefaultUserJourney ReferenceId="User journey Id" /> の直後に配置する必要があります。たとえば、<DefaultUserJourney ReferenceId="SignUpOrSignIn" /> のようにします。

次のノードを <UserJourneyBehaviors> 要素の子として追加します。

<UserJourneyBehaviors>
  <SingleSignOn Scope="Tenant" KeepAliveInDays="30" />
  <SessionExpiryType>Absolute</SessionExpiryType>
  <SessionExpiryInSeconds>1200</SessionExpiryInSeconds>
</UserJourneyBehaviors>

KeepAliveInDays と SessionExpiryInSeconds の両方を設定して、サインイン時にユーザーが KMSI を有効にした場合は、KeepAliveInDays を使用して Cookie が設定され、それ以外の場合は、SessionExpiryInSeconds パラメーターで指定された値が使用されるようにします。次の例に示すように、KeepAliveInDays の値は比較的長い期間 (30 日間) に設定できますが、SessionExpiryInSeconds の値は短期間 (1200 秒) に設定することをお勧めします。

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <UserJourneyBehaviors>
    <SingleSignOn Scope="Tenant" KeepAliveInDays="30" />
    <SessionExpiryType>Absolute</SessionExpiryType>
    <SessionExpiryInSeconds>1200</SessionExpiryInSeconds>
  </UserJourneyBehaviors>
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="displayName" />
      <OutputClaim ClaimTypeReferenceId="givenName" />
      <OutputClaim ClaimTypeReferenceId="surname" />
      <OutputClaim ClaimTypeReferenceId="email" />
      <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
      <OutputClaim ClaimTypeReferenceId="identityProvider" />
      <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

サインアウト

ユーザーをアプリケーションからサインアウトさせるときは、アプリケーションの Cookie を消去する、あるいはユーザーとのセッションを終了するだけでは十分ではありません。サインアウトさせるには、ユーザーを Azure AD B2C にリダイレクトする必要があります。そうしないと、ユーザーは資格情報を再入力しなくても、アプリケーションに対する再認証を行うことができる場合があります。

サインアウト要求時に、Azure AD B2C では次のことが行われます。

Azure AD B2C の Cookie ベースのセッションが無効にされます。
フェデレーション ID プロバイダーからのサインアウトを試みる。

Azure AD B2C の Cookie ベースのセッションが無効にされます。
フェデレーション ID プロバイダーからのサインアウトが試みられます。
- OpenID Connect - ID プロバイダーの既知の構成エンドポイントで end_session_endpoint の場所が指定されている場合。サインアウト要求で id_token_hint パラメーターが渡されません。フェデレーション ID プロバイダーでこのパラメーターが必要な場合、サインアウト要求は失敗します。
- OAuth2 - ID プロバイダーのメタデータに end_session_endpoint の場所が含まれている場合。
- SAML - ID プロバイダーのメタデータに SingleLogoutService の場所が含まれている場合。
必要に応じて、他のアプリケーションからのサインアウトが行われます。詳しくは、「シングルサインアウト」セクションをご覧ください。

注意

ID プロバイダーの技術プロファイルメタデータ SingleLogoutEnabled を false に設定することによって、フェデレーション ID プロバイダーからのサインアウトを無効にできます。

サインアウトにより、Azure AD B2C でのユーザーのシングルサインオン状態はクリアされますが、ユーザーはソーシャル ID プロバイダーのセッションからサインアウトされない場合があります。ユーザーは、その後のサインインで同じ ID プロバイダーを選択した場合、資格情報を入力しなくても再び認証される可能性があります。ユーザーがアプリケーションからサインアウトしようとする場合、そのユーザーは必ずしも自分の Facebook アカウントからサインアウトしようとしているとは限りません。ただし、ローカルアカウントを使用している場合、ユーザーのセッションは正常に終了します。

シングルサインアウト

ユーザーをAzure AD B2Cサインアウトエンドポイント (OAuth2 と OpenID Connect の両方) にリダイレクトするか、(SAML の場合) を送信すると、Azure AD B2C はブラウザーからユーザーのセッションをクリアします。 LogoutRequest ただし、ユーザーは認証に Azure AD B2C を使用する他のアプリケーションにサインインしたままになることがあります。アクティブなセッションを維持しているすべてのアプリケーションからユーザーをサインアウトするために、Azure AD B2C ではシングルサインアウト (シングルログアウト (SLO) とも呼ばれる) がサポートされています。

サインアウト中に、Azure AD B2C は同時に、ユーザーが現在サインインしているすべてのアプリケーションの登録済みログアウト URL に HTTP 要求を送信します。

カスタムポリシーを構成する

シングルサインアウトをサポートするには、JWT と SAML の両方のトークン発行者技術プロファイルで次を指定する必要があります。

プロトコル名 (<Protocol Name="OpenIdConnect" /> など)
セッション技術プロファイルへの参照 (UseTechnicalProfileForSessionManagement ReferenceId="SM-jwt-issuer" /> など)。

次の例は、シングルサインアウトでの JWT と SAML のトークン発行者を示しています。

<ClaimsProvider>
  <DisplayName>Local Account SignIn</DisplayName>
  <TechnicalProfiles>
    <!-- JWT Token Issuer -->
    <TechnicalProfile Id="JwtIssuer">
      <DisplayName>JWT token Issuer</DisplayName>
      <Protocol Name="OpenIdConnect" />
      <OutputTokenFormat>JWT</OutputTokenFormat>
      ...    
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-jwt-issuer" />
    </TechnicalProfile>

    <!-- Session management technical profile for OIDC based tokens -->
    <TechnicalProfile Id="SM-jwt-issuer">
      <DisplayName>Session Management Provider</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.OAuthSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
    </TechnicalProfile>

    <!--SAML token issuer-->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>SAML token issuer</DisplayName>
      <Protocol Name="SAML2" />
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      ...
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-issuer" />
    </TechnicalProfile>

    <!-- Session management technical profile for SAML based tokens -->
    <TechnicalProfile Id="SM-Saml-issuer">
      <DisplayName>Session Management Provider</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

アプリケーションの作成

アプリケーションがシングルサインアウトに参加するには、

SAML サービスプロバイダーの場合は、SAML メタデータドキュメントの SingleLogoutService の場所を使用してアプリケーションを構成します。アプリの登録を構成することもできます logoutUrl 。詳細については、ログアウト URL の設定に関するページを参照してください。
OpenID Connect OAuth2 アプリケーションの場合は、アプリ登録マニフェスト logoutUrl の属性を設定します。ログアウト URL を構成するには:
1. [B2C Azure ADメニューから、[を選択アプリの登録。
2. アプリケーションの登録を選択します。
3. [管理] で、 [認証] を選択します。
4. [フロント チャネルログアウト URL] で、ログアウト URL を構成します。

シングルサインアウト要求の処理

B2C Azure ADがログアウト要求を受信すると、フロントチャネル HTML iframe を使用して、ユーザーが現在サインインしている参加している各アプリケーションの登録済みログアウト URL に HTTP 要求を送信します。サインアウト要求をトリガーするアプリケーションでは、このログアウトメッセージが表示されます。アプリケーションは、ユーザーを識別するアプリケーションセッションをクリアしてサインアウト要求に応答する必要があります。

OpenID Connect OAuth2 アプリケーションの場合、Azure AD B2C は登録されたログアウト URL に HTTP GET 要求を送信します。
SAML アプリケーションの場合、Azure AD B2C は登録されたログアウト URL に SAML ログアウト要求を送信します。

Azure AD B2C は、サインアウトについてすべてのアプリケーションに通知すると、次のいずれかの操作を行います。

OpenID Connect または OAuth2 アプリケーションの場合、ユーザーは、最初の要求で指定されたstate パラメーター (省略可能) を含め、要求 post_logout_redirect_uri にリダイレクトされます。たとえば、「 https://contoso.com/logout?state=foo 」のように指定します。
SAML アプリケーションの場合、SAML ログアウト応答は、最初にログアウト要求を送信したアプリケーションに HTTP POST を介して送信されます。

ログアウトのリダイレクトをセキュリティで保護する

ログアウト後、ユーザーは、アプリケーションに対して指定されている応答 URL に関係なく、post_logout_redirect_uri パラメーターに指定された URI にリダイレクトされます。ただし、有効な id_token_hint が渡され、 [ログアウト要求に ID トークンが必要] が有効になっている場合、Azure AD B2C では、リダイレクトの実行前に、post_logout_redirect_uri の値がいずれかのアプリケーションの構成済みのリダイレクト URI と一致するかどうかが検証されます。一致する応答 URL がアプリケーションで構成されていない場合は、エラーメッセージが表示され、ユーザーはリダイレクトされません。

ログアウト要求で ID トークンを求めるようにするには、以下の手順に従います。

Azure portal にサインインします。
複数のテナントにアクセスできる場合、上部のメニューの [設定] アイコンを選択し、[ディレクトリとサブスクリプション] メニューからお使いの Azure AD B2C テナントに切り替えます。
Azure portal の左上隅にある [すべてのサービス] を選択してから、 [Azure AD B2C] を検索して選択します。
[ユーザーフロー] を選択します。
あらかじめ作成しておいたユーザーフローを開きます。
[プロパティ] を選択します。
[ログアウト要求に ID トークンが必要] を有効にします。

ログアウト要求で ID トークンを要求するには、RelyingParty 要素内に UserJourneyBehaviors 要素を追加します。次に、SingleSignOn 要素の EnforceIdTokenHintOnLogout を true に設定します。詳細については、ライブデモを参照してください。 UserJourneyBehavors 要素は、次の例のようになります。

<UserJourneyBehaviors>
  <SingleSignOn Scope="Tenant" EnforceIdTokenHintOnLogout="true"/>
</UserJourneyBehaviors>

アプリケーションログアウト URL を構成するには:

[アプリの登録] を選択してから、アプリケーションを選択します。
[認証] を選択します。
[ログアウト URL] テキストボックスに、ログアウト後のリダイレクト URI を入力し、 [保存] を選択します。

次のステップ

Azure AD B2C でトークンを構成する方法を確認します。

次の方法で共有

Azure Active Directory B2C でセッションの動作を構成する

前提条件

Azure AD B2C セッションの概要

Azure AD B2C のセッション

フェデレーション ID プロバイダーセッション

アプリケーションセッション

Azure AD B2C セッションの動作を構成する

ユーザーフローを構成する

カスタムポリシーを構成する

"サインインしたままにする (KMSI)" を有効にする

ユーザーフロー用に KMSI を構成する

ページ識別子を設定する

メタデータをセルフアサート技術プロファイルに追加する

証明書利用者ファイルを設定する

サインアウト

シングルサインアウト

カスタムポリシーを構成する

アプリケーションの作成

シングルサインアウト要求の処理

ログアウトのリダイレクトをセキュリティで保護する

次のステップ

フィードバック

その他のリソース

次の方法で共有

Azure Active Directory B2C でセッションの動作を構成する

前提条件

Azure AD B2C セッションの概要

Azure AD B2C のセッション

フェデレーション ID プロバイダー セッション

アプリケーション セッション

Azure AD B2C セッションの動作を構成する

ユーザー フローを構成する

カスタム ポリシーを構成する

"サインインしたままにする (KMSI)" を有効にする

ユーザー フロー用に KMSI を構成する

ページ識別子を設定する

メタデータをセルフアサート技術プロファイルに追加する

証明書利用者ファイルを設定する

サインアウト

シングル サインアウト

カスタム ポリシーを構成する

アプリケーションの作成

シングル サインアウト要求の処理

ログアウトのリダイレクトをセキュリティで保護する

次のステップ

フィードバック

その他のリソース

フェデレーション ID プロバイダーセッション

アプリケーションセッション

ユーザーフローを構成する

カスタムポリシーを構成する

ユーザーフロー用に KMSI を構成する

シングルサインアウト

カスタムポリシーを構成する

シングルサインアウト要求の処理