I confess I only know the high-level theory around server-side rendered Angular applications, but I’m assuming your situation is one where ultimately Javascript code running in a browser session at app.example.com would be performing XHR calls to api.example.com and would be using access tokens as proof that the caller is authorised to perform the associated actions.
In this situation, given that the access tokens would be issued by the Auth0 service then a tenant domain without a custom domain on the same second-level domain as the client application would indeed be highly constrained because the common way for the front-end to renew such tokens would be constrained by the third-party cookies situation.
My previous suggestion is both a solution and not a solution at the same time because although it would not be constrained by third-party cookie issues it also presents slightly different characteristics and would require some considerable changes.
For example, you could have tmp-ad32wzqkgoz.auth0.com as the Auth0 service domain and the same setup as before for application and API, but you would then have a flow such as:
- end-user accesses application which redirects (or opens a popup) to tenant domain for authentication.
- application receives the authentication response, validates it and since its valid initiates a local session by means of a cookie that is available both to
app.example.comandapi.example.com. - application performs XHR calls to the API by leveraging the cookie as means to prove it’s allowed to perform such actions instead of access tokens.
With the above there’s not flow where third-party cookies would be an issue as the application would not be dependent on them, but of course this has some slightly different considerations. For example, protecting the API endpoints against CSRF would be vital due to the use of a cookie for authorisation.
Have in mind that the above does not exclude the possibility for the API to also accept bearer tokens and in this way be available for other applications where the use of tokens as authorisation makes much more sense, for example, a native mobile application.