Azure AD B2C logout after session timeout

Question

Situation

I have a web application that is using Azure AD B2C as its authentication. We're using OWIN OpenIdConnect to handle this process. The session timeouts are set to 15 minutes (sessionState in web.config and on our AzureADB2C signin policy) and we have SSO enabled in the policy on the policy level. The session is set to be rolling. The OWIN CookieAuthentication is also using a 15m sliding expiry.

The web application is split into multiple parts (virtual folders) but are all sharing the same Azure AD B2C instance. However each has its own application registration in the AD. (These are basically the countries so we have www.site.com/nl and www.site.com/de for example) This to ensure that when you login you are also directed properly back to the country you were operating in. Additionally this enables us to link a country to a different AD instance should this be required.

Problem

When a user logs into the application and then subsequently logs out within his/her session the login process runs properly without issue and upon trying to login again he/she is requested to login again. This is OK and as expected.

However when a user logs in and lets his/her session expire we display a popup that asks whether you'd like to continue (links to the login page) or quit (links to the logout page). Both cases the user does not need to provide his/her credentials and this is not our desired behaviour (as this would mean if someone leaves their account open and timeout occurs anyone can still login to this account without needing to present credentials)

Oservations

1. If a user hits up the logout page after session timeout the exact same url is called https://login.microsoftonline.com/myazuread.onmicrosoft.com/oauth2/v2.0/logout?p=b2c_1_mypolicyname&post_logout_redirect_uri=https%3a%2f%2fwww.site.com%2fbe&x-client-SKU=ID_NET&x-client-ver=1.0.40306.1554 as when a user would logout during his/her session. However I see 2 different behaviours on the Azure side on this call.

A) When the session did not expire this call first calls into https://login.microsoftonline.com/my-azure-ad-guid/oauth2/logout before redirecting to my redirect uri.

B) When the session expired this call directly redirects to my redirect uri without passing over the uri in situation A.

2. There is 1 cookie difference between situation A and B called x-ms-cpim-sso:myazuread.onmicrosoft.com/b2c_1_mypolicyname it only exists in situation A which leads me to believe that this causes the different behaviour. However this is a Microsoft cookie on the login.microsoftonline.com domain so I have no control or influence over this.

3. When the login is initialized after session timeout I see calls pass by containing a clientid that does not match with any of my applications: https://login.microsoftonline.com/myazuread.onmicrosoft.com/oauth2/authorize?client_id=bb2a2e3a-c5e7-4f0a-88e0-8e01fd3fc1f4&redirect_uri=https%3a%2f%2flogin.microsoftonline.com%2fte%2fmyazuread.onmicrosoft.com%2foauth2%2fauthresp&response_type=id_token&scope=email+openid&response_mode=query&nonce=nonce&nux=1&nca=1&domain_hint=myazuread.onmicrosoft.com&mkt=en-US&lc=1033&state=StateProperties this begs the question for me what is this application and why is it being used in my auth flow causing my user not needing to re-authenticate?

Question: How do I ensure that users will need to authenticate after each session timeout?

Answer 1

UPDATE 04-09-2020: The information below is deprecated. Please take note of the notice by Microsoft:

After hearing from customers during the preview, we've implemented authentication session management capabilities in Azure AD Conditional Access. You can use this new feature to configure refresh token lifetimes by setting sign in frequency. After May 30, 2020 no new tenant will be able to use Configurable Token Lifetime policy to configure session and refresh tokens. The deprecation will happen within several months after that, which means that we will stop honoring existing session and refresh tokens polices. You can still configure access token lifetimes after the deprecation.

I believe that it may be possible to utilize the "User Signin Frequency" setting now thanks to the fact the "Persistance for Browser Sessions" is now properly done. Sadly I cannot test this so if anyone can confirm please describe in a new answer to this question how you've successfully managed this issue and I'll change the answer and direct this message to your answer.

OLD INFORMATION:

So after a few weeks of cooperation with the Microsoft Support team we finally have a closing answer and definite solution:

You are using a sign in policy. For legacy reasons, when you make a call to the /authorize endpoint for a “Sign in policy”, you first hit the Azure AD B2C service, and then immediately get rerouted to the Azure AD service. The field for username/password is then actually displayed by the Azure AD service (and not by Azure AD B2C). Once you enter a valid username/password, Azure AD stores a cookie on the client machine for SSO reasons, redirects the client back to Azure AD B2C, which then mints a token and returns a B2C token to the application, along with storing its own cookies for SSO reasons. In other words, Azure AD B2C federates to Azure AD for the sign in, and both Azure AD and Azure AD B2C have cookies of their own to maintain SSO.

Now when you call logout to Azure AD B2C or when Azure AD B2C’s session expires, Azure AD B2C does its thing to close the session, which is to delete the cookies. However, it does not delete the Azure AD cookies. Which means that when you sign in again, Azure AD B2C recognizes that you’re not signed in, and calls Azure AD. Because Azure AD has cookies planted or Azure AD’s session is not expired, it SSO’s the user and the user does not need to enter the username/password again (which is the exact behavior you do not want).

To work around this for right now, please also call the logout endpoint for Azure AD after you call the logout endpoint for Azure AD B2C. The logout endpoint for Azure AD is the same as the logout endpoint for Azure AD B2C, but without the policy in the URL. For session expiry, you will need to also limit the session timeout for Azure AD.

We are working on a sign-in policy (currently in private preview) that do not take a dependency on Azure AD. We are also looking into fixing the behavior for the original Sign in policies.

The solution to my question was indeed to limit the session timeout of Azure AD itself using policies that dictate token lifetimes. Here's the policy I set to expire in general all session on the tenant to 15 minutes (which was our desire, read the article if you want to set this policy only for specific applications etc)

Connect-AzureAD
New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1, "MaxAgeSessionSingleFactor":"0.00:15:00","MaxAgeSessionMultiFactor":"0.00:15:00"}}') -DisplayName "TokenLifetimeDefaultPolicy" -IsOrganizationDefault $true -Type "TokenLifetimePolicy"
Disconnect-AzureAD

Thanks to Microsoft Support.