Generally it is not recommended to send custom parameters to the /authorize endpoint. There is a login_hint parameter however, which is part of the standard. Generally it is used for passing the email address that the user is trying to log in as, but can also be used for this type of scenario where you want to tell the login page how to render. So, if you switch to login_hint instead of mode, then you are sticking more with that OIDC standard. Just beware that you should “validate” the value in login_hint on the login page to make sure it is either signUp or login before passing as the parameter to lock.
You can specify login_hint: “signUp” from the frontend if you want. My point was that there are other situations where you might want to set the login_hint to email . So you might want to do something like this:
@hr.stoyanov login_hint is part of the standard, you can pass it as a parameter to the authorize endpoint. You can pass any parameter as an option to the authorize call in auth0.js and it will be sent as a query parameter.
Unfortunately OIDC doesn’t give us a great solution here, signup is not addressed as well as we like, and so the options are:
we invent a new parameter and extend the spec
we re-purpose the login_hint parameter to address this instead
We tend to lean towards re-purposing the existing query parameters instead of inventing new ones and potentially causing conflicts in the future. Unfortunately both solutions are imperfect.