What is JWT? - Explanation & Meaning

What is JWT?

JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information between parties as a compact, URL-safe JSON object. JWTs are widely used for stateless authentication and authorization in modern web applications and APIs. The token itself contains all the claims needed to verify a request, eliminating the need for a central session store and simplifying horizontal scaling across services.

How does JWT work technically?

A JWT consists of three parts separated by dots: header, payload, and signature. The header contains the token type (typ: "JWT") and the signing algorithm used (such as HS256, RS256, or ES256). The payload contains claims: registered claims (iss for issuer, exp for expiration, sub for subject, aud for audience) and custom claims carrying information about the user, roles, and permissions. The signature is computed by combining the base64url-encoded header and payload with a secret (HMAC) or a private key (RSA/ECDSA). With stateless authentication, the server does not need to store session data: all required information is in the token itself and is verified on every request. Access tokens have a short lifespan (typically 5 to 15 minutes) while refresh tokens are longer-lived for obtaining new access tokens. Refresh token rotation ensures each refresh token can only be used once, enabling faster detection of stolen tokens. JWTs are ideal for microservice architectures because each service can independently validate the token using the authentication service's public key, without querying a shared database. JSON Web Key Sets (JWKS) publish public keys via a standard endpoint, so services automatically fetch the correct validation key and key rotation is handled transparently. Key security considerations include: always transmitting tokens over HTTPS, setting short expiration times, not including sensitive data in the payload (base64 is not encryption), storing tokens securely in httpOnly secure cookies instead of localStorage, validating audience and issuer claims, and preventing the "alg: none" vulnerability by enforcing the signing algorithm server-side. JWE (JSON Web Encryption) encrypts the entire token payload for use cases where the content must be confidential, unlike JWS (JSON Web Signature) which only guarantees integrity. Token binding ties a JWT to a specific TLS certificate of the client, making stolen tokens unusable on other devices. Proof of Possession (DPoP) is a newer RFC that provides a similar mechanism for public clients. When scaling microservice architectures, caching JWKS responses becomes essential to avoid overloading the authentication service, with a typical cache TTL of 5 to 60 minutes and a forced refresh on unknown key IDs. Token revocation remains a challenge with stateless tokens: common solutions include short expiration times, a token blacklist in Redis, or a combination with opaque reference tokens for scenarios requiring immediate revocation.

How does MG Software apply JWT in practice?

MG Software uses JWT as the standard authentication mechanism in our APIs and web applications. We implement an access/refresh token strategy with short-lived access tokens (10 minutes) and secure httpOnly cookies for refresh tokens with automatic rotation. In our Supabase integrations, we process JWTs for Row Level Security: the database reads claims directly from the token to enforce authorization at the row level without extra API calls. For microservice architectures, we use JWTs signed with RS256 or ES256 to authenticate requests between services without a shared session store. We publish public keys via a JWKS endpoint for automated key rotation. Custom claims are kept minimal to manage token size, and sensitive data is never placed in the payload. We implement token blacklisting via Redis for scenarios requiring immediate invalidation, such as password resets or account deactivation. Our JWT implementations include automated monitoring that alerts on unusual patterns such as spikes in expired tokens or tokens from unrecognized issuers.

Why does JWT matter?

JWTs enable scalable authentication across microservices and mobile clients without hitting a session store on every request. When the design is sound, services validate independently and you can enforce clear expiration, audience control, and key rotation for data access. For organizations offering multiple applications or APIs, JWT is the standard way to transport identity and permissions across service boundaries. The compact, URL-safe structure makes JWT suitable for HTTP headers, query parameters, and cross-domain communication. A well-designed JWT architecture reduces authentication latency because validation happens locally with cryptographic verification instead of a roundtrip to a session server. As API ecosystems grow more complex with external integrations and webhooks, JWT provides a standardized way to transfer trust across organizational boundaries.

Common mistakes with JWT

Long-lived access tokens stored in localStorage, where they are vulnerable to XSS attacks. Signing sensitive claims but not encrypting them while clients can simply read the base64-encoded payload. Weak HMAC secrets committed to source code and reusing the same secret across all environments. Failing to validate exp, aud, and iss claims, allowing expired or misdirected tokens to be accepted. Refresh tokens without rotation, so a stolen refresh token can fetch new access tokens indefinitely. Finally, accepting the "alg: none" header value, allowing attackers to submit unsigned tokens that a vulnerable library treats as valid.

What are some examples of JWT?

• A web application that returns a JWT access token after login with a 10-minute validity period, after which a refresh token in an httpOnly cookie automatically requests a new access token without requiring the user to log in again.
• A microservice architecture where each service validates incoming JWT tokens against the authentication service's public key via a JWKS endpoint, without querying a shared database and with automatic key rotation.
• A mobile app that stores JWT tokens in the operating system's secure storage (iOS Keychain or Android Keystore) and sends them with every API request in the Authorization header with a Bearer prefix.
• A Supabase-backed application where the JWT includes custom claims for user roles, so Row Level Security policies in PostgreSQL determine directly from the token which rows a user may read or modify.
• A single sign-on environment where an identity provider issues JWT tokens accepted by multiple applications, with audience validation preventing a token for app A from being reused at app B.

Related terms