Okta SignIn widget - Use email field instead of Username for Login


I am using Custom Okta SignIn Widget and I want to use email field for login instead of Username field.
Okta widget by default supports username field but I want to use Email field.
This is how my Okta UI looks -

Is there any customization provided for the same?

You can configure it under i18n configuration within the widget, like such:

i18n: {
    'en': {
        'primaryauth.username.placeholder': 'Email'

Thanks for the information.
It will only change the label name but behind the scene it will act as an username only.
Check the below screenshot for the same -

I want to apply custom validation to the field as well so that it should behave like an email field.
Like - if user doesn’t enter ‘@’, so it should prompt that “You have not enter @” or “This value is not a valid email address”

@oktadev-blog @brh55
Any help on above query would be appreciated?

Are you asking for a way to use the primary email address in the profile for authentication instead of the username? Both are usually set to the same value but they can have separate values.

Yes, I want to use email address for authentication instead of the username.
Right now, Okta Custom Sigin Widget accepts both username & email for authentication.
I just want to know, is there any way if we can use only email not username for authentication
Also, it should support bad email validation.

I would configure the Username property within the Profile Editor to be restricted to email format (Profile Editor > Okta User (Default) > Username)

I’ll assume this is a greenfield / new deployment, so this will restrict registration to meet this criteria and notify new users to meet the email format. No additional configuration on the SIW for registration. Then I would proceed with changing the language to email like I mentioned before.

In my case its “Email Format” only, but still it accepts Username and no bad email validation support.

Hi @tparikh you can’t (afaik) use the email attribute instead of the username attribute for authentication. Okta needs a combination of username and another credential like password.

To add some more insight to this, take a look at the okta authentication api. The widget uses this api behind the scenes so you can see the payload its expecting.

To achieve something like the outcome you’re looking for, I’d look at @brh55 suggestions above on formatting username to reflect an email and controlling your user registration channels. The unstated bit is that you need to make sure the email and username attributes always have the same value (and that a user can’t have non-unique email address).

My appologies, I was tied up teaching a tough Okta course and I didn’t come back to this. The widget cannot use email for authentication, because the underlying API only accepts the username: Authentication | Okta Developer. One choice that @brh55 hinted at is to require the username to match the primary email address. If your requirements can bend to meet that, it’s the easiest choice because you can stick with the widget.

If you can’t do that, then the only other solution I know is to create your own authentication application (@abole hinted at this). If you’re up for it:

This is not a trivial programming project. It must be a server-side application using an API token to access the Okta APIs. You’ll get the email address from the user and search for the matching user (primary emails are unique) using the /users API (the management SDK can help you do this). Once you find the user, retrieve the login attribute and then use the authentication SDK to authenticate with the username and password. But, you will also need to add all the transaction flows you depend, like the transaction flow when MFA is enforced. The SDK can help.

There are other issues here when you use your own authentication, mostly about how you get the user to the authentication application when an SSO application needs to request identity. What you have to do depends on wether SAML or OpenID Connect is used for the request.