A cookie associated with a cross-site resource at http://auth0.com/ was set without the `SameSite` attribute

I have read lots of posts, but none provide a clear way to remove these warnings from my browser console.

I am using “@auth0/auth0-spa-js”: “^1.6.5” and “passport-auth0”: “^1.3.2” with vue.js

please help

A cookie associated with a cross-site resource at http://auth0.com/ was set without the SameSite attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at

A cookie associated with a cross-site resource at https://happytickets.eu.auth0.com/ was set without the SameSite attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at

1 Like

Hi and welcome to Auth0 Community! @tim6

In general SPAs and native applications are not affected as far as their interactions with Auth0. “Regular” web applications, where the logic is hosted server side and renders static pages to the browser, may be affected depending on how they interact with Auth0. Specifically, applications using “response_mode=form_post” may need to use a different response mode or risk breaking compatibility with older browsers (let me know if you have more questions about this as the explanation is lengthy).

We have a document on the new SameSite requirements:

And some additional exposition here:

The auth0 servers do set cookies in the browser but we’ve already made changes on the server side to address the new requirements. For compatibility reasons we set two versions of our cookies, one with and one without the SameSite attribute, so you may see SameSite warnings for cookies named auth0_compat and did_compat. This is not a problem.

If you’re using recent versions of our SDKs cookie handling should generally be taken care of for you, but if you’re manually making HTTP calls you may need to confirm the cookie attributes. In any case there’s no substitute for functional testing–I strongly recommend enabling the new cookie handling behavior for testing:

“to test the effect of the new Chrome behavior on your site or cookies you manage, you can go to chrome://flags in Chrome 76+ and enable the “SameSite by default cookies” and “Cookies without SameSite must be secure” experiments”.

Note Chrome will not enforce the new cookie handling behavior for cookies set without a SameSite attribute less than two minutes ago. This is described in the Nov. 1, 2019 post here:

You can disable the POST+Lax behavior by setting a flag on the command line (described under the Nov. 21 post at the previous link). Firefox does not implement the POST+Lax behavior so may be easier for testing. The Firefox settings are available under about:config by setting the following flags to True:

network.cookie.sameSite.laxByDefault
network.cookie.sameSite.noneRequiresSecure

Certain extensions on the Auth0 dashboard may also need to be updated, but we’ll notify you via the dashboard and email when updates are required and available.

Additional explanation around form_post

Applications using “response_type=form_post” have several options, listed here in order of preference.
-stop using the form_post flow. This is slightly less efficient, but won’t break login flows or compatibility with older browsers.

-Set “SameSite=None” on required cookies. This may break sign in with older browsers that don’t know how to handle this attribute. A possible workaround would be to set two identical cookies with and without the attribute, but this isn’t usually possible inside a library–it would require custom work to set and read these cookies.

Please let me know if this is helpful!

1 Like

Why do you claim “this is not a problem”. it is a significant problem for me (and I imagine others). The warnings are incredibly distracting and mean other issues that would easily be spotted by reviewing the javascript console logs are being missed. Please can you stop sending 2 versions of these cookies, especially as there doesn’t seem to be any need to do this (that I can find). please can you elaborate on the “compatibility reasons”?

2 Likes

Hi @tim6

The goal of these changes are to improve security and help mitigate CSRF attacks.

These changes affect the following cookies:

  • auth0 (handles user sessions)
  • auth0-mf (handles information relevant to multi-factor authentication)
  • did (the identifier for a device/user agent)

For these cookies, Auth0 will:

  • Set the sameSite attribute to none , with the cookie requiring the use of HTTPS (regardless of environment).
  • Set fallback cookies in the event that a legacy browser does not support sameSite being set to None . These fallback cookies are auth0_compat , auth0-mf_compat and did_compat .

The default value of the SameSite cookie attribute is set to none to safeguard Auth0 customers against sessions breaking in our public cloud environment.

Also, in case you missed what are the changes you need to make: https://auth0.com/docs/sessions/concepts/cookie-attributes?_ga=2.187307496.1959161806.1586731159-335697392.1581011225#changes-you-need-to-make

2 Likes

Lily,

thanks for the response. I am afraid that I still don’t understand if it is possible to remove these warnings? And, if it is possible, I don’t know how to do it.

So, please can you be clear - is it possible to remove these warnings or do I just need to live with them?

thanks

tim

1 Like

Same here, don’t like to put an app with warnings in production. Any simple way of avoiding this messages? I followed this tutorial to setup my app:

Hi @tim6 and @kunalvm,

If you follow these steps the warnings should be cleared:

  • Update to the latest Auth0 libraries.
  • Activate the new policy in Chrome (through chrome://flags) .
  • Clear cookies, (should not see the SameSite warnings anymore).

Please let me know if that works!

1 Like

these are my options in chrome. which should i set?

also, i don’t see how this solution removes warnings for end users (on default chrome)?

Hi @tim6,

Yeah that would only work for your browser. You need to make sure you are using the latest version of the SDKs to remove warnings.

auth0-spa-js: we are now in version 1.8

Can you please confirm that you have:

  • Set your application to use sameSite=none if it uses response_mode=form_post when interacting with Auth0 (note that Chrome makes no exceptions, even for localhost )
  • Set your cookie as secure if its sameSite attribute equals None , otherwise it will be rejected by the browser. If you use HTTP for your Callback URLs, these will break if you use such cookies for binding the authorization request state/nonce. Therefore, you must either use HTTPS or set sameSite=lax .

@lily.wisecarver I’m on auth0-spa-js 1.11.0 and and @auth0/auth0-react 1.0.0 using the standard Auth0Provider authenticating to a React SPA and an API.

A cookie associated with a cross-site resource at http://auth0.com/ was set without the SameSite attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

The message is also duplicated for my own domain.

Can’t find any application settings for sameSite in the Dashboard or as a parameter to the Auth0Provider component, or to the Auth0 JS Client.