← Back to Learn
Intermediate4 April 20264 min read

OAuth & JWT — The Hotel Keycard System of the Internet

How does 'Login with Google' work? How do APIs verify you are who you say you are? Let's understand OAuth and JWT with a hotel keycard analogy.

oauthjwtauthenticationsecurity
Share:

The Hotel Keycard Analogy

When you check into a hotel:

1. You show your ID (Aadhaar/Passport) at the front desk → Authentication (proving who you are)
2. The front desk gives you a keycardToken (proof that you're authorized)
3. Your keycard opens your room, the gym, and the pool → Authorization (what you're allowed to access)
4. The keycard expires at checkout → Token expiry

You don't show your Aadhaar every time you enter the gym. You just swipe the keycard. That's how tokens work in web applications.

Authentication vs Authorization

Authentication: "Who are you?" → Login with username/password

Authorization: "What can you do?" → Admin can delete users, regular user can't

JWT (JSON Web Token)

A JWT is like a digital keycard. It contains information about the user and is signed by the server so it can't be tampered with.

eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxMjM0NX0.abc123signature
│                      │                           │
Header                 Payload                     Signature
(algorithm)            (user data)                 (verification)

How it works:

1. User logs in with email + password
2. Server verifies credentials
3. Server creates a JWT with user info and signs it
4. Client stores the JWT (usually in localStorage or cookie)
5. Every API request includes the JWT in the header
6. Server verifies the signature — if valid, request is authorized
Login:
Client → "email: sahil@email.com, password: ****" → Server
Server → verifies → creates JWT → sends back to Client

Every subsequent request:
Client → "GET /profile" + JWT in header → Server
Server → verifies JWT signature → returns profile data

Why JWT?

• Server doesn't need to store sessions (stateless)
• Works across multiple servers (no sticky sessions)
• Contains user info (no database lookup needed)

OAuth 2.0 — "Login with Google"

OAuth lets you log into App X using your Google/GitHub account WITHOUT sharing your Google password with App X.

The Analogy: You want a friend to pick up your Flipkart package. Instead of giving them your Flipkart password, you give them a one-time authorization code that only works for pickup.

The Flow (simplified):

1. You click "Login with Google" on sahilsudan.com
2. You're redirected to Google's login page
3. You log in to Google (you trust Google with your password)
4. Google asks: "sahilsudan.com wants access to your name and email. Allow?"
5. You click "Allow"
6. Google sends an authorization code to sahilsudan.com
7. sahilsudan.com exchanges the code for an access token
8. sahilsudan.com uses the token to get your name and email from Google
9. You're logged in! 🎉

Key point: sahilsudan.com NEVER sees your Google password. It only gets the specific data you authorized (name, email).

Access Token vs Refresh Token

Access Token: Short-lived (15 min - 1 hour). Used for API requests.

Refresh Token: Long-lived (days - months). Used to get a new access token when the old one expires.

Access Token expires
  → Client sends Refresh Token to server
  → Server issues new Access Token
  → Client continues making requests

Why two tokens? If an access token is stolen, the damage is limited (it expires soon). The refresh token is stored more securely and used less frequently.

Common Mistakes

1. Storing JWT in localStorage — vulnerable to XSS attacks. Use httpOnly cookies instead.
2. Not validating JWT on every request — always verify the signature server-side.
3. Putting sensitive data in JWT — the payload is base64 encoded, NOT encrypted. Anyone can read it.
4. No token expiry — always set an expiration time.

Key Takeaway

JWT = stateless authentication token (the keycard). OAuth = delegated authorization (letting a third party vouch for you). In interviews, mention JWT for API authentication and OAuth for third-party login. Always discuss token expiry and refresh token rotation for security.

👨‍💻
Sahil Sudan

Software Engineer at Spense. I write about system design, web development, and fintech — explained simply for students and developers.

📬 Stay Updated

Get a new System Design or fintech insight every week. No spam, unsubscribe anytime.

Share: