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

Problem Statement

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

Symptom

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

Troubleshooting

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

Solution

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, so this is the only scenario that these cookies will be used but they are not typically used and they are only there to provide some degree of backward compatibility: SameSite Cookie Attribute Changes. This mechanism works very well to account 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.

Another important note to this is that modern browsers default to SameSite=lax if the attribute is not present, which is actually more restrictive than the SameSite=None attribute we use for the non-compat cookies: SameSite cookies - HTTP | MDN Note that if you inspect the HTTP traffic you won’t see the attribute (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. Also, all of these cookies are set as HTTP only and Secure (only to be transmitted over HTTPS).
For users 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.