I have an app (Salesforce) using the OIDC flow for login and Sign up. We are also using ACUL.
When a user lands on the Auth0 page (login or register) and choose to ‘Register’, they are asked relevant questions before creating a username and password and then have a user created.
Is it possible to create the user record in Auth0 first but break the OIDC flow and not redirect them to the relaying party in order to capture further questions for registration? I dont want to hold the username and password in ‘memory’ as its a security issue. Comminiting the username and password to Auth0 DB seems to finish the flow and carry on the redirect.
Basically, trying to achieve:
Redirect from relaying party (salesforce) → Click sign up → create user record in auth0 → do additional sign up steps such as capture more details and IDV, saving progress at each step. → User possible stops half way → Come back to the login screen → pick up where they left off.
This isn’t using the Auth0 SDK or in a custom build app, it’s using Universal Login customised with ACUL.
I believe I know the answer - it’s a ‘no’ because you’d be breaking the OIDC flow to redirect back to the relaying party - and I believe the actual way to do this would be a custom app, using the Auth0 SDKs, however I just wanted to check I wasn’t missing anything.
1. Visitors request the app to start the authentication process 2. The application redirects visitors to the identity provider 3. The identity provider redirects visitors back to the application with a few artifacts 4. The application uses these artifacts to issue a request to the identity provider to complete the authentication process 5. The application shows a page to users containing some indication that they are logged in
You are correct that the standard OIDC flow is designed to be atomic: once the user is authenticated (or registered), Auth0 issues the tokens. It redirects back to the Relying Party (Salesforce). However, you do not necessarily need to build a fully custom app or manually break the flow.
Instead of building a custom app, you can use Auth0 Actions to create a “Progressive Profiling” or “Onboarding” flow.
Post-User Registration Action: This triggers immediately after the user is created. You can use this to tag the user (e.g., app_metadata.onboarding_complete = false).
Post-Login Action (with api.redirect): This is the key. Even though the user just registered, they are also technically “logging in” for the first time.
You can check the user’s app_metadata.
If onboarding_complete is false, use api.redirect("/your-custom-onboarding-page").
Auth0 will suspend the OIDC flow and send the user to your external onboarding site/form.
Auth0 provides a state token. When the user finishes your additional steps, your onboarding page redirects back to Auth0’s /continue endpoint, and the user picks up exactly where they left off. The username and password are already safely stored in Auth0. You are only capturing metadata. Also, if a user stops halfway, the next time they try to log in, the Post-Login Action will see onboarding_complete = false and send them right back to the onboarding steps.
If you have any further questions, please don’t hesitate to reach out.
Hi @vlad.murarasu you are 100% right, I could do progressive profiling using one of those flowsactions/triggers, however my only challenge (and why it was discounted as an option) was because it isn’t possible to customise with ACUL is it?
You are right that you cannot host a multi-step onboarding form directly within the Universal Login pages using ACUL, but that doesn’t mean you shouldn’t use the Post-Login Action approach. ACUL is designed to customize the identity pages (Login, Reset Password, MFA), not to build custom business workflows or multi-page data collection forms.
The recommended path is the Redirect Action. Host a simple, lightweight page that matches your ACUL extra data collecting page, and you should be good to go. Once the user hits “Submit” on your page, you redirect them back to the Auth0 /continue endpoint with the signed session token.
