Entra External ID - Enabled username login but client side validation requires an email

Question

Entra External ID - Enabled username login but client side validation requires an email

Chad 0

Hi all,

I have an entra external ID tenant that I have enabled username sign-in identifiers for. I can register and apply a username identity, see the username in the users but in the user flow it only allows emails to be entered.

The user:

User's image

sign-in identifier settings:

User's image

testing flow from the portal (or an app) does not allow username and fails client side validaton:

User's image

what am I missing here? I've waited 24hrs just in case it was a sync issue but no change.

This worked fine in previous tenants but I tried multiple new tenants and get the same result. Just to be sure the policy was set correctly I queried in graph and confirmed username was in the list.

Thanks

Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-05-28T14:17:36.5933333+00:00
Hey Chad, it looks like you’ve done everything right on the back end—your user really does have both an email and a username sign-in identifier (Graph confirms the username entry and it matches the default regex). What’s tripping you up is the built-in “Run user flow” page (and the default hosted UI) still renders the sign-in field as an HTML <input type="email">. That means the browser will refuse anything that isn’t in email format, so when you type “testuser” it flags it before it even talks to the policy.

Here’s what to do:

Test in an actual app • Spin up a quick sample using MSAL (or another OAuth/OIDC client) against your user flow. In that scenario you’ll see that the username “testuser” is accepted by the service.

Customize the page UI • In your customer/user flow blade go to Page layouts → Custom page content. • Upload a small HTML snippet that changes the input from type="email" to type="text". • That removes the client-side email validation, so your username flows through.

Once the field is a text box instead of an email box, your username sign-in will work just like you saw it used to in older tenants.

References

Microsoft Entra External ID overview https://learn.microsoft.com/entra/external-id/external-identities-overview

Authorize developer accounts using External ID in API Management https://learn.microsoft.com/azure/api-management/api-management-howto-entra-external-id

Create a sign-up and sign-in user flow for customers https://learn.microsoft.com/azure/active-directory/external-identities/customers/how-to-user-flow-sign-up-sign-in-customers

Customize the sign-in look and feel (page layouts) https://learn.microsoft.com/azure/active-directory/external-identities/customers/concept-branding-customers

Note: This content was drafted with the help of an AI system. Please verify the information before relying on it for decision-making.
Chad 0 Reputation points

2026-05-28T14:27:53.62+00:00

@Rukmini

Thanks for the response. I tested this out in the sample app from /ms-identity-ciam-javascript-tutorial/1-Authentication/2-sign-in-angular/SPA and got the same result. It only allowed an email to be entered.

the new layout does not have the ability to add page content. I can only alter the fields connected to the flow. I have no way I can see to change the field from email to text.

I did make a change the the default branding to re-publish that out but it did not correct the issue.
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-05-28T14:30:02.9933333+00:00

@Chad You are right that the newer External ID page layout experience no longer exposes the older custom page content capability that previously allowed changing the input field type from email to text.

Chad 0

just as a note, the actual HTML element is a text element. Additional validation is applied to enforce an email.

Inspecting the page reveals:

<input name="username" placeholder="Email address" type="text" maxlength="120" class="has-error ext-has-error ext-input ext-text-box" autocomplete="username webauthn" value="myusername" style="border-color: rgb(209, 52, 56);">

Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-05-29T09:59:46.75+00:00

@Chad

I appreciate you verifying and providing the HTML information. You're right; the External ID experience still applies extra client-side validation logic that requires email-format input, even if the control itself is now shown as `type="text".

This behavior seems to be a current product limitation or regression in the new External ID UX rather than a configuration problem in your tenant because it is consistent across tenants and official samples.

1 answer

Your answer

Chad 0 Reputation points

2026-05-28T14:27:53.62+00:00

@Rukmini

Thanks for the response. I tested this out in the sample app from /ms-identity-ciam-javascript-tutorial/1-Authentication/2-sign-in-angular/SPA and got the same result. It only allowed an email to be entered.

the new layout does not have the ability to add page content. I can only alter the fields connected to the flow. I have no way I can see to change the field from email to text.

I did make a change the the default branding to re-publish that out but it did not correct the issue.
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-05-28T14:30:02.9933333+00:00

@Chad You are right that the newer External ID page layout experience no longer exposes the older custom page content capability that previously allowed changing the input field type from email to text.
Chad 0 Reputation points

2026-05-28T14:46:02.1933333+00:00

just as a note, the actual HTML element is a text element. Additional validation is applied to enforce an email.

Inspecting the page reveals:

<input name="username" placeholder="Email address" type="text" maxlength="120" class="has-error ext-has-error ext-input ext-text-box" autocomplete="username webauthn" value="myusername" style="border-color: rgb(209, 52, 56);">
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-05-29T09:59:46.75+00:00

@Chad

I appreciate you verifying and providing the HTML information. You're right; the External ID experience still applies extra client-side validation logic that requires email-format input, even if the control itself is now shown as `type="text".

This behavior seems to be a current product limitation or regression in the new External ID UX rather than a configuration problem in your tenant because it is consistent across tenants and official samples.

Answer 1

Username sign-in in Microsoft Entra External ID requires two separate configurations to be in place and aligned with the user flow being used:

Enable username as a sign-in identifier at the tenant level
This is done in the Sign-in identifiers policy. From the screenshot, Username is already enabled with the default regex, which is correct.
Use a user flow that is configured for username/alias
The page in the screenshot that enforces an email format is the standard Email with password local account experience. That experience always validates the identifier as an email address. To allow username input instead of email in the user flow:
- In the external tenant, go to Entra ID → External Identities → User flows.
- Open the specific user flow being tested.
- Under Settings, select User attributes and ensure the Username attribute is added to the flow.
- Optionally, under Page layout, change the label of the Username field (for example, to Alias or User ID).
When the user flow is configured with the Username attribute, and Username is enabled in the sign-in identifiers policy, users who have a username identity (as in the screenshot) can sign in using either their email address or their username. The client-side validation will then accept the username value instead of requiring an email format.
Confirm behavior when testing
Use Run user flow to test. If signing in with email, preferred_username will contain the email; if signing in with username, preferred_username will contain the username.

If the user flow still shows an email-only field, verify that the correct (updated) user flow is the one being invoked by the application and that it has the Username attribute configured as above.

References: