Passwordless login keeps overwriting UserName

Hello, first time Auth0 user here.
We are playing with Passwordless only login with SMS, and I see our only option besides implementing our own Embedded Login is to use Classic Universal Login.

We managed to setup everything properly and got it working. However, whenever a user successfully logs in, “name” property/claim for that user is changed to phone number.

Manually tested if Auth0 can work without name isn’t set to phone number, thought login would match the user based on name, but that’s not the case.

We signed up with a user with SMS, when we do that phoneNumber becomes name. Then we changed the name, using it as a username and tried logging in, it was successful, but the name was forcefully changed to phoneNumber again. Looking for the optimal way to prevent this behaviour.

Hi @mithgroth

Welcome to the Auth0 Community.

The passwordless login with SMS doesn’t associate with user’s name in the login flow i.e. Universal Login only presents the user with a phone number field as a result the phone number becomes the user’s name as far as the user profile goes

If you update the user account and change the name to something else, logging back in via sms will have the same effect i.e. set name to the number as you found in testing. This seems to be expected behaviour.

What was your particular use case that you were trying to solve?

Warm regards.

1 Like

I was trying to have users pick their own unique usernames once they login, similar to a traditional authentication flow with password.

I’d highly oppose this behaviour, because:

  • Username is how other users know you, this information is publicly available to anyone
  • Exposing phone numbers publicly almost never makes sense

You already have this field as phoneNumber, why would you also use it in username?

Hi @mithgroth

I’m interested in how you’re collecting the name property as by default when using the sms passwordless flow there is no field for it as below:

Warm regards.

you are correct, since we cannot do that by default from what lock provides us, we are doing it on a custom popup tied to backend which calls to Management API.

If we PATCH the user with username, the scenario I mentioned above happens on user’s next login. Right now we are doing “the workaround”, which is using user_metadata instead.

If we can stop this behaviour (by an action, or rule?) we can just use the root element. This is relevant to our case because we can only use wildcards in Lucene Search on root elements, not user_metadata.

Also, I’m having a difficult time imagining why I or anyone would want to expose their users’ phone numbers to public, because “username” traditionally refers to the alias your identity has. Since phone numbers can be considered sensitive information, username field just loses its meaning for passwordless authentication.

Hi @mithgroth

Ok I see, thanks for sharing. Please can you log some product feedback about this detailing your thoughts and use case here so our product teams are aware of your concerns.

Many thanks.