QentiumEngineering Blog
Back to Break It Down
Break It Down

OAuth 2.0: The Hotel Key Card System Explained

Qentium TeamNov 18, 20248 min read

OAuth 2.0 sounds like a scary protocol. It has grant types, tokens, scopes, and enough jargon to fill a dictionary.

But here's the secret: it's basically a hotel key card system.

The Hotel Analogy

The Problem

You want to let a friend access your hotel room while you're away.

Option 1: Give them your main key. Now they have full access to everything—minibar, safe, everything. Too much trust.

Option 2: Get a new key card for them. You control what it opens. You can revoke it anytime. You can limit when it works.

Option 3 (OAuth): Get a temporary key card from the front desk. The desk issues it, you hand it to your friend, and it only works for your room during your stay.

That's OAuth.

The Roles

You = The Resource Owner (you own your data) Hotel Front Desk = The Authorization Server (issues key cards) Your Friend = The Client Application (wants access) The Room = The Resource Server (holds your data) The Key Card = The Access Token (grants access)

The Flow

1. **Your friend asks:** "Can I access your hotel room?" 2. **You say yes (or no):** This is "authorization" 3. **Front desk issues a key card:** This is the "access token" 4. **Your friend uses the key card:** Presents token to access the room 5. **Room validates the key card:** Checks if it's real and not expired

No sharing of passwords. No permanent access. Complete control.

Grant Types (How to Get a Key Card)

Authorization Code (The Gold Standard)

Best for web apps. More secure. Has extra steps to prevent token leakage.

  • App redirects user to authorization server
  • User logs in and approves
  • App gets authorization code
  • App exchanges code for access token
  • App uses token to access resources

Client Credentials (Machine-to-Machine)

When one server talks to another. No user involved.

  • App authenticates itself (client ID + secret)
  • Gets access token directly
  • No user approval needed

Implicit (Deprecated)

Used to be simpler but insecure. Don't use it anymore.

Scopes (What the Key Card Opens)

A key card might open: - Your room only - Your room + gym - Your room + gym + pool

Scopes in OAuth work the same way. You can request: - `read:user` - `write:profile` - `read:email`

The user (and you) decide what to approve.

The Bottom Line

OAuth isn't about sharing passwords. It's about delegating access safely.

Like a hotel key card, tokens can be: - **Limited:** Only work for specific resources - **Temporary:** Expire after a set time - **Revocable:** Can be taken back anytime

That's why it's the standard for modern authentication.