Azure AD B2C: Missing session after sign-up flow (Custom policies)

Christoph Huber 126

We have a custom sign-in/sign-up flow. The sign-up flow is divided into two separate steps like in the official custom policy example. After the sign-up flow, the client gets a valid ID token. But when Azure is asked for authentication again, I get the login page again. It seems that the session is handled differently than after a standard login flow. What might be the reason for this?

1 answer

AmanpreetSingh-MSFT 56,306 Reputation points

2022-09-06T07:12:08.023+00:00
Hi @Christoph Huber • Thank you for reaching out.

Please check if your authentication request URL includes the OAuth prompt parameter. This behavior is expected if you see prompt=login in the authentication request. If this parameter is included in the request, try to remove it to avoid the authentication prompt at each sign-in attempt.

Below is the list of all the possible values for the prompt parameter:

prompt=login forces the user to enter their credentials on that request, negating single-sign on.

prompt=none is the opposite. It ensures that the user isn't presented with any interactive prompt. If the request can't be completed silently by using single-sign on, the Microsoft identity platform returns an interaction_required error.

prompt=consent triggers the OAuth consent dialog after the user signs in, asking the user to grant permissions to the app.

prompt=select_account interrupts single sign-on providing account selection experience listing all the accounts either in session or any remembered account or an option to choose to use a different account altogether.

-----------------------------------------------------------------------------------------------------------

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.
Please sign in to rate this answer.
Christoph Huber 126 Reputation points

2022-09-06T09:41:09.06+00:00

Hi @AmanpreetSingh-MSFT
Thank you for your suggestion. My authorize request did not contain the prompt parameter, I guess the default value is not "login"? I even added prompt=none and I still get the login page. The whole URL is:
https://login.dev.gvb.ch/950e4383-db23-4b31-8311-4dbffdb2ccb0/b2c_1a_mygvb_signin/oauth2/v2.0/authorize?client_id=8b8abcfd-a5f4-494f-a0a3-ea8b4b587bec&scope=openid%20profile%20offline_access&redirect_uri=https%3A%2F%2Fmygvb.igr.gvb.ch%2Fde.html&client-request-id=c1cbc29d-b871-4c55-8ea3-a20f407fa58f&response_mode=fragment&response_type=code&x-client-SKU=msal.js.browser&x-client-VER=2.27.0&client_info=1&code_challenge=8Xh-JxWqOU9rO5xu-pv0k6Yr1Pgz8WEOS8DQmckZKjs&code_challenge_method=S256&nonce=5fefb253-c377-4c44-b799-b80d2bbad57b&state=eyJpZCI6IjMxOGM0NmVlLWQyZTYtNDYzYi1iZjE2LWEwMjYyZTIyOTQzMiIsIm1ldGEiOnsiaW50ZXJhY3Rpb25UeXBlIjoicmVkaXJlY3QifX0%3D&lang=de&prompt=none

AmanpreetSingh-MSFT 56,306 Reputation points

2022-09-12T07:49:15.38+00:00

@Christoph Huber - If the prompt parameter is not included, users should not be prompted for interactive authentication when there is an active browser session. The default value is not "login" and SSO experience should be provided.

The next thing I would suggest you check is the SingleSignOn Scope under <UserJourneyBehaviors> within the RP (signup/signin) file and make sure it is set to <SingleSignOn Scope="Tenant" />. Below is an example of how the RP file should look:

<RelyingParty> <DefaultUserJourney ReferenceId="SignUpOrSignIn" /> <UserJourneyBehaviors> <SingleSignOn Scope="Tenant" /> <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>

AmanpreetSingh-MSFT 56,306 Reputation points

2022-09-12T07:50:13.117+00:00

Possible single signon scopes are:

Tenant - This setting is the default. Using this setting allows multiple applications and user flows in your B2C tenant to share the same user session. For example, once a user signs into an application, the user can also seamlessly sign into another one upon accessing it.

Application - This setting allows you to maintain a user session exclusively for an application, independent of other applications. For example, you can use this setting if you want the user to sign in to Contoso Pharmacy regardless of whether the user is already signed into Contoso Groceries.

Policy - This setting allows you to maintain a user session exclusively for a user flow, independent of the applications using it. For example, if the user has already signed in and completed a multi-factor authentication (MFA) step, the user can be given access to higher-security parts of multiple applications, as long as the session tied to the user flow doesn't expire.

Suppressed - This setting forces the user to run through the entire user flow upon every execution of the policy.

-----------------------------------------------------------------------------------------------------------

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

Christoph Huber 126 Reputation points

2022-10-11T07:02:42.937+00:00

We did temporarily disable the UserJourneyBehaviors settings, because they cause other issues like we cannot logout anymore (see https://learn.microsoft.com/en-us/answers/questions/994601/logout-does-not-clear-session.html). As soon as we have fixed this, I will give feedback again.

Christoph Huber 126 Reputation points

2022-10-25T13:05:22.63+00:00

We could fix the logout issue and does enabled the SSO settings again:

<RelyingParty>
<DefaultUserJourney ReferenceId="MyGVBSignIn" />
<UserJourneyBehaviors>
<SingleSignOn Scope="Application" KeepAliveInDays="30"/>
<SessionExpiryType>Rolling</SessionExpiryType>
<SessionExpiryInSeconds>3600</SessionExpiryInSeconds>
<ScriptExecution>Allow</ScriptExecution>
</UserJourneyBehaviors>
...
</RelyingParty>

Unfortunately, this did not change this behavior. Do you have any other suggestion?
Sign in to comment