API Authentication: OAuth and JWT

Every API needs to answer two questions: who is this caller, and what are they allowed to do? This article walks through OAuth 2.0 for “Sign in with Google” style flows and JWTs for protecting your own API, in language you can share with frontend and mobile engineers.

OAuth 2.0

OAuth lets users delegate access without giving your app their password. For browser and mobile apps, use the authorization code flow with PKCE. Do not ship new apps on the implicit flow; it is the wrong tool for public clients.

Store refresh tokens carefully (httpOnly cookies or secure storage on mobile). Keep access tokens short-lived. Use a maintained library or identity provider so you are not hand-rolling crypto.

JWTs for your API

A JWT is a signed blob of claims (user id, roles, expiry). The API verifies the signature and trusts the claims until expiry, without hitting a session store on every request.

Rules we follow: short lifetimes (minutes to an hour), refresh tokens for longer sessions, no secrets in the payload (it is signed, not encrypted), strong algorithms like RS256, validate issuer and audience. Rotate signing keys on a plan.

Putting them together

A common pattern: user signs in through an IdP with OAuth; your auth service issues a JWT for your API. The API stays stateless for verification while still knowing who the user is.

When to get help

Auth bugs are security bugs. If you are unsure about storage, rotation, or mobile storage, ask someone who has shipped it before. We implement auth for web and mobile backends regularly.

---

Cogent Softwares, Backend and security.