# If you've ever wondered:
- $ How does a website know what I'm trying to do?
- $ Why do logins sometimes break across domains?
- $ Why do browsers hate third-party cookies so much?
- $ Why everyone says "keep your backend on the same domain"?
## The Core Idea
> Intent tokens tell the system what the user is trying to do, while cookies tell the system who the user is — and modern browsers only trust this when it all happens on the same domain.
## What Is an Intent Token?
Session Token
Your movie ticket - proves you're allowed inside the theater
Intent Token
The stamp that says "Screen 3, show at 6 PM" - proves what you're doing
## Without vs With Intent Tokens
$ curl /auth/continue
Server: "Login? Signup? Reset? Is this legit?"
## What's Inside an Intent Token?
{
"intent": "login",
"issued_at": 1700000000,
"expires_at": 1700000300,
"origin": "app.example.com",
"flow_id": "abc123"
}Short-lived
Expires in seconds or minutes
Signed by backend
Cryptographically verified
Single-use
Cannot be replayed
Describes intent
Explains why request exists
## Intent vs Session Tokens
| Feature | Intent Token | Session Token |
|---|---|---|
| Purpose | Describe action | Identify user |
| Lifetime | Very short | Long |
| Reusable | No / limited | Yes |
| Risk if leaked | Low | High |
| Example | Login attempt | Logged-in user |
## Intent Across Subdomains
👤 User clicks "Login"
app.example.com
→ Generates intent token
auth.example.com
→ Validates intent
✓ Login completed
## First-Party vs Third-Party Cookies
First-Party Cookies
Created by the site you're visiting
You visit: example.com
Cookie belongs to: example.com ✓
Trusted by browsers
Used for login, sessions, intent
Survives redirects
## Final Takeaway
Modern authentication is not broken — it's stricter.
If you design with:
- First-party cookies
- Same-domain backends
- Short-lived intent tokens
You get:
> A system that actually works in 2026 ✓