Azure-docs: Single Logout URL is never called by Azure AD B2C

[iliassk]

Is the Single Logout/Sign-out still only available for custom policies as per the current docs?

• If it is, would you please direct me to the docs I need to follow to implement it? Possibly other than these: https://docs.microsoft.com/fr-fr/azure/active-directory-b2c/session-behavior-custom-policy#configure-the-token-issuer because it doesn't really show us what we need to add to our custom policy.
• If it is not, and is now also available for built-in policies, why does Azure AD B2C fail to send a request to the configured Logout URL? It's just expecting a GET endpoint and 200 HTTP OK response, right? In any way, the call is never made when I logout from another app or the end_session_endpoint.

Thank you for any clarification.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 5761bd51-2480-33fe-0e82-c8e7b58fdcd5
• Version Independent ID: 59194957-7c80-9c86-d903-18b15022adde
• Content: SSO sessions in Azure Active Directory B2C
• Content Source: articles/active-directory-b2c/session-overview.md
• Service: active-directory
• Sub-service: b2c
• GitHub Login: @msmimart
• Microsoft Alias: mimart

[JamesTran-MSFT]

@iliassk
Thanks for your question! We will investigate and update as appropriate.

[JamesTran-MSFT]

@iliassk
I was able to look into this issue and found a Single Sign-Out SAML Protocol doc. However, besides that documentation it looks like there's still a feature request for Single Sign out in B2C.

Additionally, if you'd like to further troubleshoot your issue, can you please post it on MS Q&A so our community team can further look into the issue.

[iliassk]

The docs, I linked above, say:
When you redirect the user to the Azure AD B2C sign-out endpoint (for both OAuth2 and SAML protocols), Azure AD B2C clears the user's session from the browser. However, the user might still be signed in to other applications that use Azure AD B2C for authentication. To enable those applications to sign the user out simultaneously, Azure AD B2C sends an HTTP GET request to the registered LogoutUrl of all the applications that the user is currently signed in to.

Applications must respond to this request by clearing any session that identifies the user and returning a 200 response. If you want to support single sign-out in your application, you must implement a LogoutUrl in your application's code.

https://docs.microsoft.com/fr-fr/azure/active-directory-b2c/session-overview#single-sign-out

So it should be working for both SAML AND OAuth2.

[JamesTran-MSFT]

@illiassk
Thank you for pointing that out! I'll work with my team to help answer your original question:

Is the Single sign-out feature only available for custom policies:

• If it's still only available for custom policies, I'll see if we have any other public docs on how you can implement this.

• If it's available for built-in policies, I'll get clarification on why AzureAD B2C fails to send a request to the Logout URL. Since the call is never made when you logout from another app or the end_session_endpoint.

[JamesTran-MSFT]

@iliassk
I spoke with my team and was given the below GitHub issues for your reference. As of right now, the documentation is up to date and the only implementation/how to docs we have regarding AzureAD B2C Custom Policies can be found here.

Issues:
https://github.com/MicrosoftDocs/azure-docs/issues/34577
https://github.com/MicrosoftDocs/azure-docs/issues/49090

If you'd like to submit a feature request you can do so using this link. However, if you'd like us to continue to further troubleshoot your issue, please submit your question to our Q&A forums.

[JamesTran-MSFT]

I just wanted to check in and see if you had any other questions regarding my previous post? If not, I'll go ahead and close out this GitHub issue at the end of the day.

Thank you for your time and patience, if you'd like us to continue to further troubleshoot your issue, please submit your question to our Q&A forums.

[iliassk]

Hi @JamesTran-MSFT, I apologize for the delayed response. I was a bit discouraged by your response. None of the issues you linked answer my question.
I have no problem logging out my users on App A, when I initiate the logout on App A. The issue is when the logout has been initiated on App B. Azure AD B2C is supposed to call the Logout URI configured on App A to notify App A that the user has logged out (as per the docs and OIDC specs).

If the Single Logout-Out/Single Sign-Out is correctly implemented on your end and works as described above, I want to know:
- Why does AzureAD B2C fail to send a request to the Logout URL? Using the built-in user flow.
- If it only works with custom policies: can you please show me how can I configure my custom policy to handle the SLO. I went through this entire doc section, with no luck.

Thank you !

[JamesTran-MSFT]

@iliassk
Thank you for your time and the detailed response!

After speaking with my team, I've re-opened your issue and have reached out to our product team for further guidance/troubleshooting.

I'll update you as soon as I receive a response from their end.

[JamesTran-MSFT]

@iliassk
I just wanted to let you know that I reached out to our product team this morning and will update as soon as I hear back from them.

[JasSuri]

For custom policies, the guidance for modifying the policy files for SLO (OIDC&SAML) is here:
https://docs.microsoft.com/en-us/azure/active-directory-b2c/session-behavior-custom-policy#single-sign-out

[JamesTran-MSFT]

@iliassk
I just wanted to check in and see if the response from @JasSuri helped with your issue. It looks like the link provided points to the only location we have regarding AzureAD B2C custom policy documentation.

Please let us know if you have any other questions.
Thank you for your time and patience throughout this issue.

[JamesTran-MSFT]

@iliassk
I just wanted to check in and see if you had a chance to review the above posting by JasSuri.

If you have any other question, please let us know. Otherwise, I'll go ahead and close out your issue at the end of the week.
Thank you for your time and patience.

[JamesTran-MSFT]

Closing out the issue.

If you require additional assistance or have any questions, please feel free to tag me and I will be more then happy to continue working with you on this issue.

Thank you for your time and patience!

[iliassk]

@JasSuri @JamesTran-MSFT I've already tried what was suggested in the docs but it's not working for me. AAB2C never sends a request to my Logout URL:
Since adding a new JwtIssuer throws this error :

I changed its id. This is my configuration:

<ClaimsProvider>
      <DisplayName>Local Account SignIn</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="login-NonInteractive">
          <DisplayName>Local Account SignIn</DisplayName>
          <Protocol Name="OpenIdConnect" />
          <Metadata>
            <Item Key="UserMessageIfClaimsPrincipalDoesNotExist">We can't seem to find your account</Item>
            <Item Key="UserMessageIfInvalidPassword">Your password is incorrect</Item>
            <Item Key="UserMessageIfOldPasswordUsed">Looks like you used an old password</Item>

            <Item Key="ProviderName">https://sts.windows.net/</Item>
            <Item Key="METADATA">https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration</Item>
            <Item Key="authorization_endpoint">https://login.microsoftonline.com/{tenant}/oauth2/token</Item>
            <Item Key="response_types">id_token</Item>
            <Item Key="response_mode">query</Item>
            <Item Key="scope">email openid</Item>

            <!-- Policy Engine Clients -->
            <Item Key="UsePolicyInRedirectUri">false</Item>
            <Item Key="HttpBinding">POST</Item>
          </Metadata>
          <InputClaims>
            <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="username" Required="true" />
            <InputClaim ClaimTypeReferenceId="password" Required="true" />
            <InputClaim ClaimTypeReferenceId="grant_type" DefaultValue="password" />
            <InputClaim ClaimTypeReferenceId="scope" DefaultValue="openid" />
            <InputClaim ClaimTypeReferenceId="nca" PartnerClaimType="nca" DefaultValue="1" />
          </InputClaims>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="oid" />
            <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid" />
            <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
            <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
            <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
            <OutputClaim ClaimTypeReferenceId="userPrincipalName" PartnerClaimType="upn" />
            <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localAccountAuthentication" />
          </OutputClaims>
        </TechnicalProfile>

        <TechnicalProfile Id="JwtIssuerOidc">
          <DisplayName>JWT token Issuer</DisplayName>
          <Protocol Name="OpenIdConnect" />
          <OutputTokenFormat>JWT</OutputTokenFormat>
          <UseTechnicalProfileForSessionManagement ReferenceId="SM-OAuth-issuer" />
        </TechnicalProfile>

        <!-- Session management technical profile for OIDC based tokens -->
        <TechnicalProfile Id="SM-OAuth-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>
      </TechnicalProfiles>

    </ClaimsProvider> 

I'm not sure I'm getting where I should add this XML tag:

          <UseTechnicalProfileForSessionManagement ReferenceId="SM-OAuth-issuer" />

What am I doing wrong? Thank you!

[JamesTran-MSFT]

@iliassk
Thank you for the response and details.

I'll reach out to @JasSuri regarding this info and we will update as soon as possible.

[JasSuri]

It looks like you are putting everything in Base file, which already contains a technical profile called JWTIssuer. The error states that you have defined the technical profile with the ID JWTIssuer twice.

The snippets you posted are correctly configured, but instead take the config of JwtIssuerOidc and merge it with JWTIssuer. Then the last step in the userJourney should have a sendClaims step referencing JwtIssuer

[iliassk]

Thanks for your response @JasSuri

I applied your suggestions and exported everything to my TrustFrameworkExtensions.xml :

<ClaimsProviders>
        ...
        <ClaimsProvider>
            <DisplayName>Token Issuer</DisplayName>
            <TechnicalProfiles>
                <TechnicalProfile Id="JwtIssuer">
                    <Protocol Name="OpenIdConnect" />
                    <Metadata>
                        <Item Key="token_lifetime_secs">28800</Item>
                        <Item Key="id_token_lifetime_secs">3600</Item>
                        <Item Key="refresh_token_lifetime_secs">86400</Item>
                        <Item Key="rolling_refresh_token_lifetime_secs">86400</Item>
                        <Item Key="IssuanceClaimPattern">AuthorityAndTenantGuid</Item>
                        <Item Key="AuthenticationContextReferenceClaimPattern">None</Item>
                    </Metadata>
                    <UseTechnicalProfileForSessionManagement ReferenceId="SM-OAuth-issuer" />
                </TechnicalProfile>
            </TechnicalProfiles>
        </ClaimsProvider>

        <ClaimsProvider>
            <DisplayName>Session Management</DisplayName>
            <TechnicalProfiles>
                <!-- Session management technical profile for OIDC based tokens on SLO (Single Log-Out)-->
                <TechnicalProfile Id="SM-OAuth-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>
          </TechnicalProfiles>
     </ClaimsProvider>
</ClaimsProviders>

My GET /api/slo endpoint is now correctly called by the IdP but Azure AD B2C doesn't include any information about the session that should be invalidated/logged out. My app is stateful.
Usually, other IdPs call the targeted Logout URI by including the domain's browser cookies. Am I missing some configuration in my custom policy? Here are the request parameters:

:authority: localhost:443
:method: GET
:path: /api/slo
:scheme: https
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
referer: https://<tenant>.b2clogin.com/<tenant>.onmicrosoft.com/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Flocalhost%3A5555&p=B2C_1A_custom_signup_signin
sec-fetch-dest: iframe
sec-fetch-mode: navigate
sec-fetch-site: cross-site
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.61 Safari/537.36

[JasSuri]

Adding the cookies would be the browser&domain combo, B2C has no control on what cookies are presented at your endpoint. There shouldn't be anything further to configure in policy now.

[iliassk]

Then I don't get why the cookies are added by the browser when the request is directly sent via the browser and not added when the request is sent via Azure AD B2C after a logout?

[JasSuri]

I'm not sure either, it should work with just a redirect as B2C is doing.
Wonder if its a same-site cookie issue, anything in the Browser console?

[iliassk]

That was it.
On both Firefox and Chrome, same-site on the session cookie has to be set to None instead of Lax:
This cookie was blocked because it had the "Samesite=Lax" and the request was made from a different site and was not initiated by a top-level navigation

I guess it's blocked because the Azure AD B2C request was not initiated by a top-level navigation?

Also, for those using incognito mode, be sure to disable this:

[JamesTran-MSFT]

@iliassk
I just wanted to check in and see if you still required JasSuri's assistance on this issue? Or if setting same-site to none resolved your issue.

Please let me know if you have any other questions.
Thank you again for your time and patience throughout this!

[iliassk]

Yes, it does resolve my issue but it's probably not the best solution security-wise. I was wondering what was @JasSuri opinion about this. Is it a limitation of the way AADB2C is calling the Logout URI endpoint?

But yes, you can close the issue. Thank you for your assistance James!

[JamesTran-MSFT]

@iliassk
Thank you for the confirmation! I'll go ahead and close out this issue.

@JasSuri, when you get the chance, would you be able to respond to iliassk's question above? Regarding your opinion on this issue.