Auth0 Home Blog Docs

Auth bug: SAML + required username database connections



I’m running into an issue for both Auth0 SDK v9, and Lock v11. I’m running the QuickStart tutorial for React, with Node v9.7.1 on MacOs.

I have a 2 connections set-up for this client: a SAMLP enterprise connection, and a database connection (using the one provided by Auth0). The enterprise connection has an associated email domain (we can call it

With the above, the sign-up tab of the widget works as expected. If I enter a email, the password field collapse and I am can redirect to the identity provider, and I can sign-up correctly.

When I activate the “Requires username” on the database connection, the sign-up form now has the extra username field. When i enter a email, the password and username fields don’t collapse anymore (which is my expectation of how it should behave). If I try to sign-up using a email, fill in the username and password fields, and press submit, I am presented with an error message:

Here’s the HAR file: auth0-bug.har (791.7 KB)

To reproduce:

  • Use the React Quickstart repo, set up a SAMLP connection & a database connection with username required.

Let me know i there’s anything i can provide to help debug this issue,




That indeed seems to be an issue; when the username option is enabled Lock seems to be getting the user identifier from the username field for the purposes to detect if this is enterprise connection associated or not, but in my view it should always get that from the email field. You can check this yourself, if you input the email address associated with the enterprise connection as the username field then Lock reacts correctly.

Given this is indeed a bug it should be tracked through the Lock repository ( and should be reported there; given that you already collected all the details let me know if you prefer to just re-create this as an issue there yourself, if not I can raise an issue there myself.



Ah indeed, I’m getting the intended behaviour when putting the email in the username field. I’d be better for me if you could the issue directly.

Thanks a lot!



Reported at:


Hi @jmangelo,

Do you have any update on the progress for a fix to this issue? (I’m not sure if I should ask here, or on the GitHub issue board)




I’m afraid I have no update on the situation and if you can then it may indeed be worthwhile to leave an inquiry in the GH issue itself.


I checked internally and I have some news, although not the best ones. It seems that the behavior although unexpected can be driven by the Lock option usernameStyle. In particular, I was informed that if you set that option to email then the behavior in question should no longer happen during signup. It can still be argued that even without that option set like that by the email field should always be used for this purpose instead of the username one, however, given this would be a change in visible behavior as you can also set that option to be username at this time there’s no indications that there will be changes in Lock so my recommendation would be to consider the possibility to use the above option set to email, for example, you can different Lock configurations where one only shows signup and has that option set and another one only used for login.



Thanks for getting back to me. Yeah you are right, we probably need to go for the option you suggested of having multiple configurations depending on whether we’re doing a sign-up or a log in.