3rd party cookies

ben_leen11 · May 29, 2018, 2:00pm

Our team is using the deprecated Cross Origin authentication (using "/usernamepassword/login).
We’re about to move to the newer “/co/authenticate” using custom domains.
Custom domains exist because you decided, rightfully so, that 3rd party cookies could be expected not to be enabled (especially in e.g. an enterprise setting).

However… We noticed that using silent authentication (which is an iframe visiting the auth0 domain) cookies are also NOT being sent. In this context they’re also considered 3rd party cookies.
The result in our current set-up is that a user is instantly logged out when the browser is trying to renew the session; the session cookie is not being sent.

Does this mean that your clients, using the hosted login page/universal login for their SPA, should be concerned about their users having 3rd party cookies enabled?

luis.rudge · May 29, 2018, 5:23pm

If you use the Universal Login Page, everything works just fine with or without custom domains. The issue arises when you’re trying to authenticate to a another domain (myapp.com authenticating to myapp.auth0.com) and the other domain tries to SET the cookie (myapp.com > SET-COOKIE myapp.auth0.com ). This operation will fail if you don’t use custom domains. When you use the universal login page, the cookie is set in the same domain (myapp.auth0.com/login > SET-COOKIE myapp.auth0.com), which will work and all subsequent calls to myapp.auth0.com should also send the cookie.

ben_leen11 · May 29, 2018, 10:07pm

I realize now that I should have been more specific. The issue I’m raising actually isn’t about 3rd party cookies specifically but what kind of cookies browsers (Chrome in this case) will block if you turn on the feature “Block third party cookies”. In Chrome, for example, it seems to also be blocking 1st party cookies if sent via an iframe. Which might be indicated by the flavour text; “Prevent third-party websites from saving and reading cookie data”.

To be more specific: even with our current usage of “/usernamepassword/login” the browser will redirect to the Auth0 appliance domain (self submitting form against “/authorize”) and Auth0 will, as a last response in the authentication, reply with a redirect statuscode (back to the app), a Set-Cookie header with HttpOnly session cookie and an id/access_token for immediate use. Even with “Block third party cookies” enabled in chrome I can clearly see this cookie being set. Great!

Now, when silent authentication is triggered after, due to session renewal being invoked via the Auth0 library. An iframe will be created by the Auth0 library, targetting the Auth0 domain to get a new token (using the session cookie) and then renew the current HttpOnly 1st party session cookie that was there. However, with “Block third party cookies” enabled the mentioned 1st party HttpOnly cookie is not sent in the previous step. Chrome seems to block it due to the “Block third party cookies” feature being turned on (I assume to avoid tracking).

Now, I could be wrong but isn’t universal login also relying on Silent Authentication to renew Auth0 SSO sessions?

github.com

auth0/auth0.js/blob/072ced2473e4ada2e2b85002226424e2daada9e0/src/web-auth/index.js#L380


      
          * @param {String} [options.nonce] value used to mitigate replay attacks when using Implicit Grant. {@link https://auth0.com/docs/api-auth/tutorials/nonce}
          * @param {String} [options.scope] scopes to be requested during Auth. e.g. `openid email`
          * @param {String} [options.audience] identifier of the resource server who will consume the access token issued after Auth
          * @param {String} [options.postMessageDataType] identifier data type to look for in postMessage event data, where events are initiated from silent callback urls, before accepting a message event is the event expected. A value of false means any postMessage event will trigger a callback.
          * @param {String} [options.postMessageOrigin] origin of redirectUri to expect postMessage response from.  Defaults to the origin of the receiving window. Only used if usePostMessage is truthy.
          * @param {String} [options.timeout] value in milliseconds used to timeout when the `/authorize` call is failing as part of the silent authentication with postmessage enabled due to a configuration.
          * @param {Boolean} [options.usePostMessage] use postMessage to comunicate between the silent callback and the SPA. When false the SDK will attempt to parse the url hash should ignore the url hash and no extra behaviour is needed
          * @param {authorizeCallback} cb
          * @see {@link https://auth0.com/docs/api/authentication#authorize-client}
          */
          WebAuth.prototype.renewAuth = function(options, cb) {
           var handler;
           var usePostMessage = !!options.usePostMessage;
           var postMessageDataType = options.postMessageDataType || false;
           var postMessageOrigin = options.postMessageOrigin || windowHelper.getWindow().origin;
           var timeout = options.timeout;
           var _this = this;
          
          
 var params = objectHelper
             .merge(this.baseOptions, [
               'clientID',

github.com

auth0/auth0.js/blob/072ced2473e4ada2e2b85002226424e2daada9e0/src/web-auth/index.js#L418


      
          
          
params.prompt = 'none';
          
          
params = objectHelper.blacklist(params, [
            'usePostMessage',
            'tenant',
            'postMessageDataType',
            'postMessageOrigin'
          ]);
          
          
handler = SilentAuthenticationHandler.create({
            authenticationUrl: this.client.buildAuthorizeUrl(params),
            postMessageDataType: postMessageDataType,
            postMessageOrigin: postMessageOrigin,
            timeout: timeout
          });
          
          
handler.login(usePostMessage, function(err, hash) {
            if (typeof hash === 'object') {
              // hash was already parsed, so we just return it.
              // it's here to be backwards compatible and should be removed in the next major version.

github.com

auth0/auth0.js/blob/5de1165d9e34864fd68193d387356c9142666c95/src/web-auth/silent-authentication-handler.js#L23


      
              windowHelper.getWindow().location.origin ||
              windowHelper.getWindow().location.protocol + '//' + windowHelper.getWindow().location.hostname
                + (windowHelper.getWindow().location.port ? ':' + windowHelper.getWindow().location.port : '');
          }
          
          
SilentAuthenticationHandler.create = function(options) {
            return new SilentAuthenticationHandler(options);
          };
          
          
SilentAuthenticationHandler.prototype.login = function(usePostMessage, callback) {
            this.handler = new IframeHandler({
              auth0: this.auth0,
              url: this.authenticationUrl,
              eventListenerType: usePostMessage ? 'message' : 'load',
              callback: this.getCallbackHandler(callback, usePostMessage),
              timeout: this.timeout,
              eventValidator: this.getEventValidator(),
              timeoutCallback: function() {
                callback(null, '#error=timeout&error_description=Timeout+during+authentication+renew.');
              },
              usePostMessage: usePostMessage || false

luis.rudge · May 30, 2018, 2:42am

Ah, ok. Thanks for the clarification. Yes, Chrome and possibly other browsers with 3rd party cookies disabled won’t send the cookie when you try to call checkSession. IE/Edge, for example, send the cookie anyway.

ben_leen11 · May 30, 2018, 11:33am

I’m a bit surprised that this isn’t mentioned somewhere other then here:

Am I right to say that this matrix is almost just as relevant for any implementations using silent authentication with or without using the cross-origin authentication feature.
It would be useful have a similar matrix reported here:

and/or

luis.rudge · May 30, 2018, 4:03pm

You’re absolutely right. I’m talking with the docs teams right now to add a section about this in relevant docs. I’ll keep you posted in this thread.

florent.jaby · August 19, 2018, 11:18pm

This also took me the better half of a day and should definitively appear in the docs for silent authentication. Silent authentication is ultimately a premium feature, seeing that it requires custom domains to work properly on 85% of browsers (not IE/Edge)

JanErikFoss · December 14, 2018, 12:40pm

So I just found this after a day of debugging why my iPhone is stuck in a login loop.

I spent all day yesterday migrating from embedded to universal login to work around the third party cookies issues. Do I have to fork over money to make it work on newer browsers after all?

JanErikFoss · December 20, 2018, 9:00am

I can confirm that custom domain fixes the silent authentication issue, and by extension fixes the redirect loop on iOS 12 safari.

konrad.sopala · February 11, 2019, 6:12pm

Thanks a lot @JanErikFoss for sharing it with the rest of community!

system · February 26, 2019, 6:12pm

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.