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

開始する前に、[ポリシーの種類の選択] セレクターを使用して、設定するポリシーの種類を選択します。 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 アプリケーション、モバイル アプリケーション、またはシングル ページ アプリケーションによって管理されるセッション

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 プロバイダーによって決定されます。

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

1. ユーザーが Facebook にサインインして、フィードを確認します。
2. その後、ユーザーがアプリケーションを開き、サインイン プロセスを開始します。 アプリケーションでは、ユーザーを Azure AD B2C にリダイレクトして、サインイン プロセスを完了します。
3. 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) の手順を完了している場合、複数のアプリケーションのセキュリティの高い部分へのアクセス権をユーザーに付与します。 このアクセスは、ユーザー フローに関連付けられているセッションがアクティブなままである限り続行されます。
  • [抑制] - この設定は、ユーザー フローを実行するたびに、ユーザーにユーザー体験全体を強制的に実行させます。

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

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

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

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

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

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

2. まだ存在しない場合は、<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>
   

3. Scope 属性の値を、Suppressed、Tenant、Application、または Policy のいずれかの値に変更します。 詳細については、RelyingParty のリファレンス記事を参照してください。

4. SessionExpiryType 要素を Rolling または Absolute に設定します。 詳細については、RelyingParty のリファレンス記事を参照してください。

5. SessionExpiryInSeconds 要素を 900 秒 (15 分) から 86,400 秒 (24 時間) の間の数値に設定します。 詳細については、RelyingParty のリファレンス記事を参照してください。

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

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

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

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

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

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

1. Azure portal にサインインします。

2. 複数のテナントにアクセスできる場合、上部のメニューの [設定] アイコンを選択し、[ディレクトリとサブスクリプション] メニューからお使いの Azure AD B2C テナントに切り替えます。

3. Azure portal の左上隅にある [すべてのサービス] を選択してから、 [Azure AD B2C] を検索して選択します。

4. [ユーザー フロー (ポリシー)] を選択します。

5. あらかじめ作成しておいたユーザー フローを開きます。

6. [プロパティ] を選択します。

7. [セッションの動作] で [[セッションにサインインしたままにする] を有効にする] を選択します。 [セッションにサインインしたままにする (日数)] の横に、1 から 90 までの値を入力して、セッションを開いたままにする日数を指定します。

   

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

ページ識別子を設定する

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

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

2. BuildingBlocks 要素を検索します。 要素が存在しない場合は追加します。

3. 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 技術プロファイルを上書きします。

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

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

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

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

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

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

1. カスタム ポリシー ファイルを開きます。 たとえば、SignUpOrSignin.xml などです。

2. まだ存在しない場合は、子ノード <UserJourneyBehaviors> を <RelyingParty> ノードに追加します。 <DefaultUserJourney ReferenceId="User journey Id" /> の直後に配置する必要があります。たとえば、<DefaultUserJourney ReferenceId="SignUpOrSignIn" /> のようにします。

3. 次のノードを <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 では次のことが行われます。

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

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

注意

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 トークンを求めるようにするには、以下の手順に従います。

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

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

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

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

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

次のステップ

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