Security & Access

JSON Web Token (JWT)

Term 23 of 68 in the ERPStack technical glossary

What is JSON Web Token (JWT)?

A JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact, self-contained way for securely transmitting information between parties as a JSON object, signed cryptographically.

JSON Web Token (JWT) at a glance

Specification: RFC 7519, published May 2015 by the IETF
Structure: 3 base64url segments — header, payload, signature — separated by 2 dots
Critical rule: Verify the signature and reject 'alg: none'; the payload is encoded, not encrypted
Lifetime: Short-lived access tokens plus a revocable refresh token, because a signed token cannot be un-issued
Built with: JWT verification in Next.js 16 middleware, signing keys held in AWS, refresh tokens in PostgreSQL 18 or Redis, RBAC claims checked in server actions, failures reported to Sentry
Numbers that matter: RFC 7519, May 2015; 3 segments separated by 2 dots; 4 checks on every verify — signature, algorithm, expiry, audience; 0 secrets in the payload
Compare with: Server-side sessions in Redis or PostgreSQL 18, revocable immediately, or an OAuth introspection call per request
Commonly paired with: OAuth flows, SSO, RBAC claims, Redis or PostgreSQL 18 refresh storage, Next.js 16 middleware and Sentry on verification failures
Claims to keep small: A subject identifier, a tenant identifier and an expiry — not a profile. Claims are validated with Zod 4 on arrival and resolved against roles held in PostgreSQL 18 through Drizzle ORM 0.45.
What reviewers sample: Token lifetime, signing-key rotation and revocation at offboarding — the 3 items SOC 2 and ISO 27001 access reviews test across a Multi-tenant Architecture.

How JSON Web Token (JWT) works in production

JWTs are commonly used for stateless session management. When a user logs in, the authentication server signs a JWT containing the user's ID, role, and expiration timestamp. The client stores this token and sends it with every API request. Middlewares decode and verify the signature to grant access without querying the database.

The ERPStack approach to JSON Web Token (JWT)

We utilize short-lived JWT tokens for session authorization, configuring aggressive client-side cleanup and token refresh rotations to maximize access security.

Related Resources

Frequently asked questions about JSON Web Token (JWT)

What is a JSON Web Token and what is it for?

A JSON Token is a compact, signed statement of claims that a service can verify without calling the issuer. Defined in RFC 7519, published in May 2015, it carries a header, a payload of claims and a signature across 3 base64url segments. Its value is stateless verification: any service holding the key can trust the contents without a database lookup on every request.

Is data inside a JWT encrypted?

No, and assuming otherwise is the most common security error with this format. A JSON Token payload is base64url encoded, which is reversible by anyone holding the token, so it must never carry secrets, personal data beyond an identifier, or anything you would not put in a log. The signature guarantees integrity and origin — it does not provide confidentiality.

How should token expiry and revocation be handled?

With short lifetimes and a separate refresh path. A signed JSON Token remains valid until it expires, so there is no way to withdraw one already issued. Keeping access tokens short-lived limits the damage window, while a longer-lived refresh token stored server-side can be revoked immediately. Systems that issue 30-day access tokens have effectively no logout.

What must a verifier always check?

The signature, the algorithm, the expiry and the audience. Accepting the algorithm named in the token itself allows the classic 'alg: none' bypass, so the verifier must fix the expected algorithm. It should also confirm the JSON Token was issued for this service rather than another one sharing the identity provider, since a valid token for a different audience is still a valid signature.