We intended to implement a custom OTP implementation using the “Redirect Users from rules” feature similar to the example documented here: Redirect Users from Within Rules . The feature is explicitly referred to as relating to redirect but the important part to us is the ability to suspend/resume the authentication flow using the state value.
We are currently using /oauth/ro and have no easy migration path so want to keep using it (see SPA with custom login page. Upgrading Auth0js from v7 to v8 - Auth0 Community).
The “Redirect Users from rules” feature is not compatible with /oauth/ro since it’s consumed as an ajax call. Do we have alternatives that would not involve upgrade to v8, redirects or sso sessions? E.g.: Any way to get the ‘resume’ state in the rule itself (to call another endpoint from the rule) or maybe include ‘resume’ state in the json response for /oauth/ro?
I also understand the flow can’t continue from an ajax call so a redirectUrl being passed in on the initial ‘/auth/ro’ call would be needed with anticipation on OTP.
Since you want to use redirect rules to implement a custom MFA (which is a smaller subset of the possibilities that redirect rules would allow), you could consider one alternative.
Using /oauth/token (instead of /oauth/ro) with MFA (currently only Auth0’s Guardian and Google Authenticator). This is detailed in this doc here.
However, this option should only be considered for highly trusted clients which are capable of storing client secrets securely. That means that for SPAs, we highly recommend against using the resource-owner password grant flow (but would instead recommend the redirect-based implicit grant flow). This means that depending of your application type this may not be an alternative.
Additionally, from what I understand about your specific case, I believe that you want to build a custom OTP solution (and not merely use one of the MFA options I mentioned), which means you really want to use redirect rules.
In that case, the options are:
- Use
/authorize (for the authorization code grant, implicit grant or the PKCE flows); this would allow you to use a redirect rule and support token renewal due to the use of a session. Have in mind this also involves a redirect to the hosted login page so this may not be an option because you would lose your embedded login.
- Wait for a new feature. We’re working on a new flow which allows for credentials to be entered on your client application (and exchanged via an XHR much like
/oauth/ro), followed by a non-interactive redirect through /authorize where your redirect rule can come into effect. This flow will support SSO/token renewal and allows you to embed the login page in your client.
I understand, that since option 1. is not applicable because you do not want to have the user stop at the hosted login page and option 2. is not yet available these end up as non-real options, but it’s what I’m aware of at the moment. I can additionally inform you that the functionality related to option 2. is being actively worked on and is not something just on our backlog, nonetheless, I can’t promise you a definitive ETA.