I’m trying to provide custom password validation. Currently, this can be accomplished by using a Custom Database, and checking the password in the “Login” action. However, this requires that I then provide all the other functionality, such as storing the user profile in my own database, etc. Is there any way to provide a custom Login function, and use defaults for the other required functions (i.e. still use Auth0 for user storage)?
Since I’m using external JWTs as user passwords in this case, I can’t use the normal password check mechanism, since they’ll change.
When implementing a custom database connection the login script is the only one mandatory to implement. The remaining ones are optional as long as you don’t depend on the associated functionality. More specifically, if you don’t delete users through Auth0 you won’t need that script, if the password is not really a password then you don’t need the change password script and so on…
The login script should indeed return some profile information about the user, but that does not imply that all or any information needs to be stored in a custom store. For example, if you only want to return an email field in the basic profile and that data is available within the JWT itself then you would not even need any custom store.
Also have in mind, that independently of how the user authenticates you will then be able to associate additional data stored by Auth0 to that specific user (for reference information see User Data Storage Guidance). This means that even if your custom database connection does not directly map to a real database you can still associate metadata to the user which is stored by Auth0 itself.
This would be very similar to users that authenticate through social connections where the social identity providers return some profile information which you can then complement using metadata stored in Auth0 itself and not at the social identity provider.