Hi there,
I am trying to answer a very simple question : Is it possible to use the Free tier with Safari or any browser that would have 3rd party cookies blocked ?
AFAIK, you need custom domains for Auth0 to work properly in that situation (users are logged out upon refresh), meaning the free tier is useless.
From the last sentence of this document , it sounds as if there would be a way around it, using universal login. However, this seems to contradict this other doc and that one.
I have also seen in multiple places that Universal Login could allow for users sessions to be preserved upon refresh, e.g in this tutorial (refer to the “Keeping Users Signed In after a Refresh” section). However the tutorial makes use of checkSession() which fails on 3rd party cookie blocking browsers.
Finally, I stumbled upon that thread when trying to implement Auth0 Lock, but none of the suggestions worked for me.
I find it very unprofessional from Auth0 to be so misleading when it comes to such a simple thing.
I don’t have a definitive answer for you, but where I work we are using our auth0.com tenant domain name with single sign-on across many applications & application types (SPA, regular web app, etc.), domains, and browsers, and it all works. However, we’re not on the free tier so maybe there’s something else that is different. We do have our custom domains configured, but haven’t started using them.
I’ll have a closer look at the docs you linked to. If I can help at all, happy to do so.
I don’t think that this is such a simple thing; at least some time ago the definition of third-party cookies was very browser-specific, as in, a browser would consider a specific cookie third-party in one context while other browsers would not if the context is the same. I confess that this may have changed as I haven’t researched this topic in detail recently, but I would not call this simple by any means.
You also need to consider that getting into the situation of this being an issue at all requires a decision to implement an application in a way that it can be susceptible to this. In particular, if you have a web application that upon authentication establishes a local session (cookie-based) with an application-specific backend that lives in the same domain as the web application then this would be mostly a non-issue.
With regards to the documentation I won’t argue that it could likely be less confusing, but I think calling it misleading is a bit unfair. As you mentioned we have specific documentation calling the attention to the fact that some flows are constrained by the browser.
From my very personal opinion, if I was in a situation where I would have to implement a web application for the general public I would strongly consider not depending on the browser-side for token/session management and would likely have a web application with a cookie-based session that would be bootstrapped by a token-based response.
Appreciate your answer, which brings a bit of perspective.
However, I have been following Auth0 docs and tutorials, so I am not sure what you mean by :
I would strongly consider not depending on the browser-side for token/session management and would likely have a web application with a cookie-based session that would be bootstrapped by a token-based response.
I am in somewhat of a specific situation, as I am using Server Side Rendered Angular (Angular Universal), and my API will be on a separate server. Both will live on the same domain though, under app.mydomain.io and api.mydomain.io.
You can absolutely use Auth0 on the free tier. If you implement authentication according to the documentation and quick starts, you’ll see Auth0 recommends using the Hosted Login Page. On the free tier, that page lives on *.auth0.com. If you pick another tier, you can indeed use a custom domain, but that doesn’t impact the fundamental functionality of the Hosted Login Page.
Now, if you want to use things like Embedded Lock, yeah, you’ll need a custom domain to not trigger the 3rd party cookies block. That’s not Auth0 being greedy, that’s browsers blocking anything and everything to preserve user’s privacy. Guess we have Facebook and Google to thank for that
I strongly recommend you stick to the best practices laid out in the docs and quick starts: use the Hosted Login Page.
Best practices changed recently in regard to storing tokens. It could be that some of the docs aren’t quite updated yet. I encourage you to check out this:
And to give you even more to read (sorry): the implicit flow is no longer a best practice for SPA. You should try to use the Authorization code grant with PKCE now.
I hope this helps. Please feel free to ask any questions you still have!
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.com and api.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.
Thank you @thijmen96@jmangelo for helping out on this topic.
I have gone the custom domain route for now using Auth0 universal, which seemed like the most simple way forward.
I will definitely keep an eye on the Authorization code grant with PKCE in the future, but for now it seems a bit overkill.
