Problem statement
We have a customer that has custom password complexity requirements (min-length) that differ from the min-length for the rest of our customers.
Currently, our password validation is managed in-house, and we’d like to migrate it to Auth0-managed. For that, we would need to be able to use some sort of parameter (e.g., email-domain) to differentiate the different password complexity requirements. From documentation and our current testing, it seems we can only create one min-length requirement for all users per database connection.
Is there a way we could do this with Auth0?
Solution
This use case is possible by using multiple database connections; each connection can have its own password settings. If your customers are using a separate application, then this is simple to implement since you can just enable each connection for the corresponding application.
However, if you need to have these separate database connections all used by the same application (client ID), then there is a bit more work required to hint to Auth0 which database connection should be used. Without any of the following workarounds, Auth0 will just use the first enabled database connection to attempt to authenticate the user’s username and password.
Database connections don’t have home realm discovery capabilities like Enterprise connections, but there are some potential workarounds:
The downside to those offerings is they require using the Classic Universal login page which is not possible with the New Universal Login page.
Another workaround that would allow you to keep using the New Universal Login page is to provide some way for your application to send the user to the /authorize endpoint with a “connection” query string parameter. This will force Auth0 to use the desired database connection, and all other connections enabled for that client will be unavailable for that login transaction. This could be a page you host that provides some form of domain lookup, or different login buttons, for example, or you could use vanity URLs in your application and have your code modify the authorize parameters based on the URL the customer is using.
- See this documentation.
The final option is to use Organizations; this will constrain which connections are available to the user based on the Organization they are logging into. You could then represent your different customers as different Organizations.