Some gotchas with configuring Entra External ID

The Gotcha Group, LLC, Public domain, via Wikimedia Commons

Entra External ID is the “successor” to Azure AD B2C, and there are many similarities, but there are slight differences in how things are done that may catch you out.

Hopefully, this post will save you some time 😃

The portal URL is entra.microsoft.com, not portal.azure.com.

Let’s register an application. We can save time by not using a client-side app. so configure the URL for jwt.io.

Now let’s create a user flow. We’ll use “email with password” to log in.

Note that you can only configure the attributes you want to collect at sign-up, not the ones you want in the JWT.

Now, let’s create a new external user.

Now, let’s edit the properties.

Note that first and last names are not populated, so let’s fill in those fields.

Back to user flows and “Run user flow”.

We have to link an application to the user flow.

Many applications can use the same user flow, but many user flows cannot use the same application.

Link the application.

The fact that the application is linked to the user flow (policy) means that the URL no longer has to contain the policy name.

Rerun the user flow.

After logging in:

in:

You need admin approval.

Back to the application.

Grant admin consent.

Rerun the user flow.

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

We get this JWT???

Back to enterprise applications and SSO:

Edit the attributes.

You have to do them one at a time.

Rerun the user flow.

We get the same three incorrect attributes in the JWT.

Back to application registrations.

In Authentication, select “ID tokens”.

This is specifically required for jwt.io.

Rerun the user flow.

And we get:

error_description=AADSTS50146 This application is required to be configured
with an application-specific signing key. It is either not configured with 
one or the key has expired or is not yet valid.

The fix for this bizarre error message is to edit the manifest in the app. registration.

Set “acceptMappedClaims”: true.

Rerun the user flow.

The JWT now looks like:

{
  ...
  "sub": "qVT...g68",
  "tid": "7fb...3bb",
  "uti": "gnp...BAA",
  "ver": "2.0",
  "Display name": "Medium Post",
  "Given name": "Medium",
  "Surname": "Post"
}

Bingo!

One other gotcha is that you have to use conditional access to set up MFA.

Currently, the only available MFA methods are OTP and SMS.

If you use “email with password” in “email accounts” in the user flow, you can use either method.

If, however, you use “email one-time password”, you can only use SMS.

The docs. are here.

Also note that “Reset password” sends a code to the email address, unlike B2C, where the app had to handle the message.

All good!