Compat Cookie Attributes

Problem Statement

Can the SameSite attribute of the *_compat cookies be set/changed?


  • auth0 cookie SameSite attribute set to None
  • auth0_compat and did_compat cookies not having a SameSite attribute present


Log a user in and notice the values of the auth0 cookies on the responses.


The *_compat cookies are configured by Auth0 as a fallback mechanism in case a user is on an older browser that doesn’t support the SameSite attribute; this is their sole purpose.

  • These older browsers need the cookies without the SameSite attribute for the flow to work to provide backward compatibility: SameSite Cookie Attribute Changes.
  • This mechanism accounts for all the different ways old browsers treat/reject the “Samesite” attribute when it’s unknown. It has proven to be a much more robust solution than trying to guess the browser behavior based on the user agent header.

Note: Modern browsers default to SameSite=lax if the attribute is not present, which is actually more restrictive than the SameSite=None attribute used for the non-compat cookies: Set-Cookie

  • If the HTTP traffic is inspected, the attribute won’t be there (the server is not setting it), but modern browsers will behave as if the attribute was provided with a “lax” value.

Because modern browsers default to “samesite=lax” (a stricter setting than “samesite=none” used by the “non-compat” cookies), these cookies do not represent an additional security concern for users using these browsers.

  • All of these cookies are set as HTTP only and Secure (only to be transmitted over HTTPS).
  • When using older browsers, the security risk is also not affected: the cookies with the “samesite” attribute are ignored, and the “compat” cookies are received and treated as if they had “samesite=none” (the only behavior browsers handled at that time). But they are still sent with “httponly” and “secure”, as recommended for these cases.