Security · March 22, 2026

JWT claims that stay boring in production

Token design is mostly about removing surprises. A small claim set, strict validation rules, and a single issuer policy do more than a long list of clever flags.

Minimum useful claim set

For an API-first backend, the claims that usually matter are straightforward: `sub`, `iss`, `aud`, `iat`, `nbf`, and `exp`. The identity is clear, the token source is explicit, and time-based checks stay auditable.

What not to overload into the token

Roles, feature flags, and workspace-specific state can become stale faster than token lifetimes suggest. If the server must frequently question that data, it should probably not trust it as static token content.

Validation should read like a checklist

Request handling becomes easier when validation remains mechanical: verify signature, verify issuer, verify audience, verify clock-based claims, and only then load application-level authorization context.

Boring auth is a feature. If engineers can explain rejection logic in one breath, incident handling gets materially easier.

Why this matters for Placefolio

The product will likely gain collaboration, invitation, and shared project access. Keeping JWT claims narrow prevents authentication concerns from swallowing authorization concerns too early.