OAuth2, JWT, and Session Tokens Explained with Diagrams

Authentication can be confusing — especially when buzzwords like OAuth2, JWT, and session tokens get thrown around interchangeably. This guide breaks it all down with clear diagrams and real-world analogies, so you’ll finally understand how modern authentication actually works.

🧩 What Are We Trying to Solve?

Before diving into tokens and protocols, let’s start with the basic question:

“How can a server know that a user is authenticated?”

Answer: By giving them a token — a temporary proof of identity. How that token is issued, validated, and stored depends on whether you’re using sessions, JWTs, or OAuth2.

🔐 1. What Are Session Tokens?

Session tokens are the classic way to manage user authentication.

🟢 How It Works:

1. User logs in (e.g., with email/password)
2. Server creates a session and stores it in its memory or database
3. Server sends back a session ID
4. The browser stores the session ID (usually in a cookie)
5. On every request, the session ID is sent back to the server
6. The server looks it up and confirms the user is logged in

🧠 Diagram:

[ Client ] <-- login --> [ Server ]
           <-- session ID --
[ Client ] <-- sends session ID on each request -->
[ Server ] <-- looks up session ID --> user info

✅ Pros:

• Simple and secure (if cookies are configured properly)
• Server controls session expiration

❌ Cons:

• Doesn’t scale well with microservices or mobile APIs
• Requires shared session storage across servers

🧾 2. What Is JWT (JSON Web Token)?

JWT is a self-contained token that contains the user’s identity and claims — like a digitally signed note.

🟢 How It Works:

1. User logs in
2. Server creates a JWT (with user ID, email, etc.)
3. JWT is sent to the client (stored in localStorage, cookie, etc.)
4. Client sends the JWT on each request (usually in the Authorization header)
5. Server verifies the signature, reads the token, and trusts the user

🧠 Diagram:

[ Client ] <-- login --> [ Server ]
           <-- JWT Token --
[ Client ] <-- sends JWT on each request -->
[ Server ] <-- verifies JWT --> reads user info from token

✅ Pros:

• No need to store sessions on the server
• Ideal for stateless APIs
• Easy to use with mobile apps and microservices

❌ Cons:

• Can’t be revoked unless you maintain a blacklist
• If compromised, the token is valid until it expires

🌐 3. What Is OAuth2?

OAuth2 is not an authentication protocol — it’s an authorization framework.

It allows third-party apps (like yours) to access a user’s data without getting their password.

Example: “Log in with Google” or “Connect to GitHub”

🟢 How It Works:

1. User clicks “Log in with Google”
2. App redirects to Google’s OAuth2 server
3. User grants access
4. Google redirects back with an authorization code
5. App exchanges the code for an access token
6. App uses the token to fetch user data

🧠 Diagram:

[ Client ] --> [ Google OAuth ]
           <-- grant access
[ Client ] <-- authorization code --
[ Server ] --> [ Google Token API ] --> access token
[ Server ] --> [ Google API ] --> user info

✅ Pros:

• Secure and standardized
• Used by Facebook, Google, GitHub, etc.
• Tokens can have scopes (e.g., read-only)

❌ Cons:

• Complex setup
• Often confused with login — need OpenID Connect for identity

🔄 Session vs JWT vs OAuth2 (Quick Comparison)

Feature	Session Tokens	JWT	OAuth2
Stored On Server	✅ Yes	❌ No	❌ No
Scalable for APIs	❌ No	✅ Yes	✅ Yes
Token Revocation	✅ Easy	❌ Difficult	✅ Built-in
Used For Login?	✅ Yes	✅ Yes	⚠️ Not always*
Example Use	Traditional web apps	Mobile / SPAs	“Log in with…”

*OAuth2 handles authorization; for authentication, it should be paired with OpenID Connect (OIDC).

🧠 Real-World Analogy

• Session Token: You’re on a guest list at a party — the bouncer checks it every time.
• JWT: You carry a signed badge with your name and role — anyone can verify it.
• OAuth2: You give permission to a friend (the app) to access your house using a key from your landlord (Google).

✅ When Should You Use Each?

Use Case	Best Option
Web app with server	Sessions
Mobile app or SPA	JWT
Third-party account login	OAuth2 + OIDC
Microservices backend	JWT or OAuth2

🏁 Final Thoughts

Modern authentication can feel like a maze, but it all comes down to trust — and how you prove it.

• Use sessions for simplicity and control
• Use JWTs for scalable, stateless APIs
• Use OAuth2 when delegating access or logging in via third-party services

👉 Want a deep dive into implementing these in Flutter, Node.js, or Spring Boot? Stay tuned — we’ve got tutorials coming.