Authentication: JWT and OAuth Basics With easy examples.

Authentication is proving who you are — logging in. JWT (JSON Web Token) and OAuth are the two technologies behind most modern logins. A JWT is a small signed pass the server gives you after login; you attach it to every request instead of logging in again. OAuth is a protocol that lets you log in to one app using another account — the familiar "Sign in with Google" button — without sharing your password.

Nearly every app needs login, and insecure login is dangerous. JWTs keep APIs stateless and fast; OAuth spares users another password. Every web developer must understand both.

Key Concepts

• Authentication vs authorization: authentication proves identity (who you are); authorization decides permissions (what you may do). Login is the first; access rules are the second.
• JWT structure: three Base64 parts — header, payload, signature. The payload holds claims (user id, expiry); the signature proves no tampering.
• Access token: a short-lived JWT (often 15 minutes) sent with each API request.
• Refresh token: a long-lived token (often days) used to get new access tokens without asking for the password again.
• OAuth 2.0 roles: the resource owner (user), the client (app), and the authorization server (e.g. Google) verifying identity.
• Scope: the specific permissions a client requests, like "read your email" — shown to the user for approval.

How It Works

A typical login with JWT follows these steps:

1. You send your username and password to the server over HTTPS.
2. The server verifies them and creates a signed JWT with your user id and expiry.
3. Your app stores the token and attaches it to every API request in the Authorization header.
4. The server verifies the signature per request — no database lookup — and trusts the claims.
5. When the access token expires, the app silently uses the refresh token to get a new one.

The OAuth "Sign in with Google" flow is similar, except Google verifies your identity and hands the app a token, so your password never touches the app at all.

Worked Example

Access tokens last 15 minutes, refresh tokens 7 days. An 8-hour workday = 480 minutes, needing 480 ÷ 15 = 32 access tokens, fetched silently via the refresh token. In seconds: access = 900s, refresh = 7 × 24 × 3600 = 604,800s. A stolen access token dies in 15 minutes, but a stolen refresh token lasts a week — hence secure httpOnly-cookie storage and server-side revocation.

Common Misconceptions

• "JWTs are encrypted." By default they are signed, not encrypted — anyone can read the payload. Never put passwords or secrets in a token.
• "OAuth means the app sees my password." The opposite: with OAuth the app never receives your password. Google (or another provider) checks it and only tells the app "this user is verified."
• "A valid signature means the user is authorized for everything." The signature only proves identity. The server must still check permissions — a valid token for a normal user must not access admin endpoints.

Real-World Applications

JWTs secure mobile apps, single-page apps, and microservices — the server verifies tokens without session storage, scaling effortlessly. OAuth powers "Sign in with Google/Apple/GitHub" buttons and integrations like calendar access, where scopes limit what the app may do. Banks combine short-lived tokens with refresh rotation so stolen tokens quickly die. For students, implementing JWT login is a rite of passage in full-stack projects.

In short: JWTs are signed passes proving identity per request; OAuth lets apps borrow your identity without seeing your password. Keep access tokens short-lived, guard refresh tokens, and check authorization separately from authentication.