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

Help
1

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
2

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:

https://www.chromium.org/updates/same-site

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
4

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”?

1 Like
5

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: SameSite Cookie Attribute Changes

2 Likes
6

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
7

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:

8

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
9

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

image
image740×376 37 KB

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

10

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 .
11

@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 Chrome Platform Status and Chrome Platform Status.

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.

1 Like
12

Hi @lily.wisecarver

Can you follow up with how to resolve this?

1 Like
13

Hey there @Kaphis!

Let me ping @lily.wisecarver on this one.

14

Hi @michael_hindley,

The cookies concerned come from auth0.com and is a server concern. There is nothing that the SDK can do to change this.

We have already changed the server side to set the samesite attribute accordingly - if you inspect the network tab, you should see the auth0 cookie come down with samesite set to None in Chrome. I can verify that I’m getting the warning too, yet cookies seem to be set OK and everything still works. What we can’t understand is why Chrome is still showing the warning but everything still seems to work.

If you are still concerned, please try the following:

  • Inspect the actual cookie attributes and verify whether the samesite attribute is being set correctly
  • Enable the samesite flags in Chrome, or download the Canary release of Chrome (which has the flags set by default) and verify that calls to getTokenSilently() still work

If you are concerned that something isn’t working properly as it should, let me know.

2 Likes
15

@lily.wisecarver Not all cookies from /auth0.com/oauth/token have SameSite set to None in the response, the “did_compat” cookies value for SameSite is empty, while the others are None or Lax, maybe thats the one triggering the console spam in chrome?

image
image904×121 18.6 KB

16

So what do we do in this case. The SDK says it’s the server and the server is saying it’s the SDK. All of which we are following sample code and tutorials on how to use auth0-js with Auth0 platform

1 Like
17

Hey, any news on this? We are running "auth0-js": "^9.13.2", and the login isn’t working for most browsers.

18

I had this issue, was very distracted by it, but ultimately resolved it by reading and understanding this:

My assumption is that, like me, those of you having this issue (a) see it exclusively in your local dev environment, and (b) your local server is not using HTTPS (in which case, no problem) —OR you are seeing the message in production because your server isn’t using HTTPS. (In which case, say thanks for the warning and fix that!)

This isn’t a bug; things are working as designed.

Chrome is providing a deprecation warning because what we are doing by running a server with HTTP is actually violating the secure cookie policy set by Auth0.

If you are not using HTTPS in production, the warning is doing you a favor. Enable HTTPS!

In my case, I was seeing these warnings in local dev environment and was distracted and concerned by them.

I imagine if I made a cert and used HTTPS for local development, the warning would go away because I would be complying with the policy. The warning isn’t about something Auth0 is doing, but that I am personally violating the cookie policy Auth0 set. (How dare I!)

The non-HTTPS local dev environment works right now, but presumably at some point it won’t work any longer or perhaps there will be some sort of localhost exemption in Chrome’s implementation of this policy or perhaps Auth0 will implement a ‘dev mode’ toggle in their interface that sets the cookie policy to lax.

I am going to trust that this will be fully resolved by the time the policy goes into effect.

So—what did I do to solve this for myself?

For my own diligence, I verified the problem does not exist in production where I am running HTTPS. (It doesn’t.)

Then I went into chrome://flags and disabled Cookie Deprecation messages.

Non-problem “problem” solved :slight_smile:

Hope that helps!

—

P.S. My recommendation to Auth0 would be:

Create an addition to docs regarding the SameSite warning being caused by local HTTP rather than HTTPS and in that doc:

  1. Provide some assurance that this is almost certainly not something people will see in production
  2. Educate Auth0 users about what will be expected from local environments when the policy goes into effect.
  3. Advise that if they find the messages distracting, the best course of action is to disable the deprecation warning.
2 Likes
19

Glad you have eventually figured it out and thanks for providing that feedback Adam!

20

Thank you for your post and feedback @adamavenir! I have submitted your docs request directly to our Product Team for further review. Please let us know if there is anything else that we can assist with at this time. :slight_smile:

3 Likes
21

I still have this issue on Chrome 84 in local development in Auth0 tutorial (Vuejs + node API). Did anyone solve this?