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