auth.mydomain.com is white-listed as callback url. We have sub-domains for each user where they will have access to dashboard from userId.mydomain.com/app after login.
When the user finally ends up in userId.mydomain.com/app after login flow (Step 4), the session seems to be lost. Session is maintained until Step 3.
We don’t store any session data in session/localstorage as advised in your docs. So my guess is session in memory gets cleared in the final redirect (Step 3 → Step 4). Is there a way to continue the session from Step 3 to Step 4?
In this situation we need to have in mind that from step 3. to step 4. the action being done is outside of the scope of the identity provider (in this case an Auth0 service). This means that addressing this issue will require custom implementation on your side.
As you pointed out for SPA (browser-based application) the quickstarts have been updated to not rely in Web Storage and instead just keep required artifacts in memory. However, for this scenario this change/recommendation is not relevant; the Web Storage API’s are isolated per web origin and in your situation you have multiple web origins in your system, in particular, you have the equivalent origins to:
https://auth.example.com - initiates the authentication to the identity provider and handles the identity provider response.
https://userId.example.com - user dashboard.
Given that you want to share an authenticated session between the above origins which technically also represent completely independent browser-based applications then you need to choose a means to share this session in a suitable way for your apps.
Given different web origins Web Storage is immediately out of the equation as it would not be shared. One possible way to share a session between different subdomains is having a cookie at the parent domain, but as I mentioned at the start you then need to manage this cookie yourself.