How to share cookies between two different websites
Use a common top-level domain
If the two websites share a common top-level domain like .example.com, you can set cookies to be shared across subdomains by setting the Domain attribute:
Set-Cookie: name=value; Domain=.example.comThis allows the cookie to be sent in requests to any subdomain of example.com.
Redirect “ping-pong”
Have site A redirect to site B with a token in the URL, B sets a cookie and redirects back to a callback on A, which can then set its own cookie.
Post messages
Site A and Site B can communicate via postMessage if they are open in the same browser. Site A can send the cookie value to B which can set its own cookie.
What are first-party and third-party cookies?
First-party cookies match the domain of the current site displayed in the browser’s address bar. Third-party cookies are from domains other than the current site. A cookie can be either first-party or third-party depending on which site the user is visiting.
Sites may have content from different domains, leading to a mix of first-party and third-party cookies.
How does CSRF rely on cookies?
Cross-site request forgery (CSRF) attacks work by exploiting the fact that cookies are automatically attached to any request to a domain, even if initiated by another site. For example, if evil.example triggers requests to your-blog.example, the victim’s browser will attach the associated cookies. This could allow actions like deleting posts unless the target site properly validates the requests.
How to explicitly state cookie usage?
The SameSite cookie attribute can explicitly state whether a cookie should be restricted to first-party or same-site contexts. This prevents the browser from sending the cookie along with cross-site requests, mitigating CSRF risks.
What is SSO?
Single sign-on (SSO) allows a user to authenticate once with a single ID provider and gain access to multiple applications and systems without reauthenticating. This improves the user experience.
How to implement SSO across subdomains?
A common way is to have an identity provider subdomain like id.example.com. When a user visits a.example.com, they are redirected to the identity provider to authenticate. After signing in, the identity provider redirects back with a token that a.example.com validates before setting a user session. This allows SSO across subdomains.
How can SSO work across different domains?
With separate domains, the sites cannot directly share cookies. An alternative is to use a redirect “ping-pong” flow between the identity provider and each application to pass identity information through URL parameters or POST data rather than cookies.
How does SAML enable SSO?
SAML (Security Assertion Markup Language) is an open standard that defines an XML-based framework for exchanging authentication and authorization data between identity providers and service providers. This eliminates re-authentication across sites supporting SAML.
How does OAuth enable SSO?
OAuth allows an application to access resources on behalf of a user without exposing their credentials. The user authenticates directly with the OAuth provider, which then issues access tokens to the application. This separates authentication from authorization and enables SSO.
How can JWTs enable SSO?
JSON Web Tokens (JWT) are a compact way to securely transmit identity data as a JSON object. They can be signed and/or encrypted. The signature verifies the token is from the identity provider. JWTs enable SSO by propagating identity across sites.
ref: