Add case-insensitive option for user by email search

Feature: Add case-insensitive option for user by email search

Description:

Right now, Get Users By Email search allows searching by email, but only in case-sensitive way. We need a case-insensitive search option, which is immediately consistent. There is Get Users endpoint where search by email is case-insensitive, but that endpoint is eventually consistent.

Use-case:

We have a requirement in our systems that user email is unique. We want to enforce email uniqueness by implementing an Auth0 Action (eventually we might consider account linking, but right now this is not an option for us). Email needs to be unique across all connections, regardless of case, for example “user@example.com” and “User@Example.com” should be treated as same email/user.

To implement this, we need to check if there is an existing user with same email. We are using Retrieve Users with Get Users by Email Endpoint endpoint, because it is immediately consistent, so it’s safe to use in this scenario. However, for this endpoint search by email is case-sensitive. This means that if there is a user in our database which signed up with e.g. Passwordless (e.g. “user@example.com”), and then a user tries to sign up with social login with same email, but not lowercased (e.g., “User@Example.com”), we will not find the existing user and allow login, resulting in two users with same email.

There is Retrieve Users with the Get Users Endpoint endpoint where search by email is case-insensitive, but as mentioned in the docs that endpoint is eventually consistent, so not safe for our scenario.

Ideally, the Get Users by Email endpoint would accept additional parameter to enable case-insensitive search. There is a related community discussion, where multiple users are requesting this feature: Email Search Casing Should Not Matter

Thanks for sharing a detailed use-case!

This endpoint being case sensitive, it ends up being pretty much useless or at least too dangerous to rely on. We have users coming from enterprise connections with email address like Some.User@company.com and we can’t find them.

2 Likes

Seconded! Exactly the same use case here. Enterprise (AD) connection keeps casing as it is, and we have a hard time finding these users.

Thanks everyone for sharing it! We’re gonna update you as soon as we have news to share!

Hi - sharing the same experience - have setup two enterprise connections who had AzureAd and occasionally coming through as Pascal case - issue when searching for users

1 Like

Adding my experience as well. We had a user who wanted to do a password reset. We utilize the users-by-mail endpoint to check if they are already in Auth0 to send them a different email if they are not. And since they used different casing, it kept coming back as not found. This is high priority for us to get changed. Thanks.

I also like to have this feature; again similar case of Enterprise connection with AAD which creates users with upper case

1 Like

Auth0 - this has been long time limit/flaw of the user model , users email should be unique no matter the case - when is this going to be fixed ?

2 Likes

Agreed! Is there any timeline for this?

2 Likes

We are hit by this too! Can we prioritize this so we don’t have to jump through hoops? We hit this when integrating Azure AD SSO

1 Like

We have the same exact use case. When using Okta SSO we get emails with upper case and we can’t match emails that are lower case, or mixed case.

3 Likes

Any plans on fixing this issue?

1 Like

Surely this is an easy 2 minute fix? I cannot see where it makes sense to have an email case sensitive.

Might as well add another opinion to the pile in hopes that it finally topples over.

We had a bug pop up today due to the fact that this one is case sensitive and the create user endpoint isn’t.

Case-insensitive search is SORELY needed. We’re literally hammering the endpoint with every possible casing just to get all possible users since our users come in via username/password and myriad SAML connections (god only knows what their casing is). So case-sensitive search is actually resulting in huge overhead just to get the data we need.