1

I have an asp.net MVC application that uses Azure AD B2C for authenticating users.

Up till now we where using only the built-in userflows for signup and signin, but now I created a custom flow for a specific scenario. I used this getting started document for the custom flow: https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-get-started

My problem is that the Tokens generated by the built-in flows are signed by a different key than the tokens generated by the new custom flow.

In the startup.cs I reference the MetaDataAddress for the default built-in flow (that has a reference to the signing keys in it)

app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
{
    MetadataAddress = https://contoso.b2clogin.com/contoso.onmicrosoft.com/[built-in-flow]/v2.0/.well-known/openid-configuration,
}

When the new custom flow token is validated, it should not validate to the key in the metadata-address defined above, but to a different signing key.

How can I make sure the token is validated correctly for both built in and custom flows? Or How can I make sure the tokens created in the custom and the built in flows use the same signing key.

Mark Prins
  • 11
  • 1
  • How about adding an IF statement to set the metadataAddress based on the policyId? You cannot make them use the same signing key. – Jas Suri - MSFT Nov 21 '20 at 01:10

1 Answers1

0

It's not supported to work seamless between user flows and custom policies. There is a session management technical profile called out in the custom policy - see more on technical profile. Or visit here to read and different session managements. There is no UX to connect keys between the two solutions.

The application calling to Azure AD B2C (the login endpoint) is different as well - as it must explicit needs to add the policyID when submitting a request to the Azure AD B2C endpoint.

The most common scenarios that I've seen using a mix between user flow & custom policy:

  • Using user flow for the password reset flow and custom policy with SUSI (sign-up sign-in)
  • Deploying to different departments that operate independently (no SSO is needed between the two ever)
Chad Hasbrook
  • 206
  • 1
  • 6