JWT (JSON Web Token)
A JSON Web Token (JWT) is a compact, URL-safe token standard (RFC 7519) for securely transmitting information between two parties. JWTs are used in modern Web Apps as an authentication mechanism: after login, the client receives a signed token that is sent with every API request to verify the user's identity.
Structure of a JWT: Header, Payload, Signature
A JWT consists of three Base64-encoded parts separated by dots: Header (algorithm and token type), Payload (claims: user ID, roles, expiration time) and Signature (cryptographic signature using a secret key). The server validates the signature with every request – any manipulation of the payload invalidates the signature. JWTs are signed but not encrypted – the payload is readable.
Why JWT instead of session cookies?
Traditional session authentication stores state on the server (session store). JWTs are stateless: the token contains all necessary information, so the server does not need to maintain state. This simplifies scaling and Microservices architectures. However, token invalidation (e.g., on logout) requires a blacklist, which partially negates the statelessness advantage.
JWT security: best practices
Short expiration times (15–30 minutes) for access tokens. Refresh tokens with longer lifetimes for token renewal. HttpOnly cookies instead of localStorage (prevents XSS access). Signing keys managed as dedicated secrets in Secret Management . Token rotation: each refresh issues a new token pair and invalidates the old one. CSRF protection for cookie-based token transport. Two-Factor Authentication as an additional layer of protection.
JWT and OAuth 2.0
JWTs are frequently used as the token format in OAuth 2.0 flows. OAuth 2.0 defines the authorization flow (how a token is requested), while JWT defines the token format (how data is structured). OpenID Connect (OIDC) builds on OAuth 2.0 and standardizes the use of JWTs for identity tokens. The combination enables secure single sign-on solutions.
How we use it
In our Django REST backends, we transport JWTs exclusively in HttpOnly cookies – never in localStorage, to eliminate XSS attacks. Access tokens expire after 15 minutes; refresh tokens are rotated on every use and invalidated via a Redis blacklist. The JWT signing key is managed as a separate secret, distinct from the Django SECRET_KEY, and injected via Secret Management in the CI/CD pipeline. CSRF protection is additionally active.