The Mystery: One Login, Multiple Services
Log into Gmail and you're automatically logged into YouTube. Open Google Calendar and it recognizes you. Visit Google Drive and you're already authenticated. This isn't magic—it's a carefully designed system using cookies and domain attributes.
Understanding how cross-domain authentication works is crucial for:
- Building secure authentication systems
- Understanding browser security models
- Acing frontend interview questions
- Debugging authentication issues in production
The Naive Solution: Separate Cookies Per Domain
This doesn't scale. Google's ecosystem has dozens of services. Asking users to log in for each one would be a UX nightmare.
The Solution: The Domain Cookie Attribute
HTTP cookies have a Domain attribute that controls which domains can access a cookie. This is the key to cross-domain authentication.
// Example Set-Cookie header from Google's servers
Set-Cookie: sessionid=abc123xyz789; Domain=.google.com; Path=/; HttpOnly; Secure; SameSite=LaxNotice the Domain=.google.com (with a leading dot). This tells the browser:
- .google.com - This cookie can be accessed by gmail.com, youtube.com, calendar.google.com, and ANY subdomain of google.com
- Path=/ - Available for all paths on those domains
- HttpOnly - Not accessible via JavaScript (security measure)
- Secure - Only sent over HTTPS connections
- SameSite=Lax - Protects against CSRF attacks
How It Works in Practice
The Cookie Behavior Chart
| Scenario | Domain Attribute | Result |
|---|---|---|
Domain=gmail.com | Exact domain only | ❌ Only gmail.com gets the cookie |
Domain=.google.com | All subdomains | ✅ gmail.com, youtube.com, calendar.google.com, etc. |
| No Domain attribute | Current domain only | ❌ Only the exact domain that set it |
Domain=google.com | google.com + subdomains | ✅ Same as .google.com in practice |
The Critical Security Boundary
If you try to set Domain=.facebook.com from your website, the browser will reject it. This protects users from cross-site cookie attacks.
This is called the Public Suffix List (PSL). The browser maintains a list of "public suffixes" (like .com, .co.uk, .github.io) and prevents cookies from being set at these levels.
// What Google CAN do (owns google.com)
gmail.com → can set Domain=.google.com ✅
// What Gmail CANNOT do (doesn't own facebook.com)
gmail.com → cannot set Domain=.facebook.com ❌
// browser rejects this for securityThird-Party Cookies vs. First-Party Cookies
| Type | Definition | Example |
|---|---|---|
| First-Party | Cookie from the domain you're currently on | gmail.com sets a cookie for .google.com while you're on gmail.com |
| Third-Party | Cookie from a domain different from the address bar | Facebook pixel on your website tracking users across the web |
Google's approach is technically first-party cookies—they own all the domains. Real third-party tracking (by ad networks) is increasingly restricted by browsers.
SameSite Cookies: Modern Security
Modern authentication adds another layer: the SameSite attribute. This protects against CSRF attacks.
SameSite=Strict
// Cookie sent ONLY if request originates from the same site
// Clicking a link from external site → cookie NOT sent
SameSite=Lax
// Cookie sent for top-level navigations (user clicks link)
// But NOT for embedded requests (iframes, images)
SameSite=None
// Cookie sent everywhere (requires Secure flag)
// Used for cross-site scenarios like embedded paymentsGoogle uses SameSite=Lax because:
- User experience isn't harmed (normal clicks still work)
- CSRF attacks are prevented (form submissions blocked)
- Widely supported across browsers
Real-World Example: The Google Login Flow
Why This Design is Brilliant
- Single Sign-On (SSO): Log in once, access everywhere
- Centralized Security: One auth server validates all requests
- Consistent User State: All services share the same session
- Scalable: Works for any number of services under the same domain
- Secure: HttpOnly prevents XSS, Secure ensures HTTPS, SameSite prevents CSRF
Interview Question: The Full Answer
❓ "How does Google keep you logged in across Gmail, YouTube, and Calendar?"
The Short Answer: Google uses the Domain cookie attribute set to .google.com, which makes the session cookie accessible across all Google subdomains.
The Detailed Explanation: When you log into Gmail, Google's authentication server creates a session cookie with Domain=.google.com. This tells the browser that this cookie should be sent to any subdomain of google.com.
The cookie includes:
Domain=.google.com- Accessible by all Google subdomainsHttpOnly- Protects against XSS attacksSecure- Only sent over HTTPSSameSite=Lax- Protects against CSRF attacks
The Security Aspect: This is safe because Google owns all these domains. The browser won't allow cookie setting for domains you don't own, enforced by the Public Suffix List.
Key Takeaways
- HTTP cookies have a
Domainattribute that controls which domains can access them Domain=.google.commakes cookies accessible to all subdomains- This enables Single Sign-On (SSO) across multiple services
- Browser security prevents setting cookies for domains you don't own (Public Suffix List)
HttpOnly,Secure, andSameSiteattributes provide additional security- First-party cookies work seamlessly; third-party cookies are increasingly restricted
- This is a foundational web security pattern used by every major tech company
Further Exploration
- MDN Web Docs: Set-Cookie Header
- Read about: OAuth 2.0, OpenID Connect for more advanced authentication patterns
- Experiment: Open your browser DevTools → Application → Cookies and look at google.com cookies
- Advanced: Study how JWT tokens improve upon cookie-based authentication
You Now Understand Cross-Domain Authentication 👆
Understanding cookies is one thing. Explaining this confidently in an interview under pressure is another entirely.
Join Cohort 3 Waitlist →