What is JWT Claims?
The signed JSON assertions inside a JSON Web Token, such as subject, expiry, issuer, and role. Services trust claims only after verifying signature, issuer, audience, and expiration together.
Example
An API route accepts a bearer JWT, verifies signature plus expiry, issuer, and audience, then reads the role claim for authorization. Expired tokens earn a 401 even when the signature itself still checks out.
What people get wrong
Trusting claims from an unverified token, or skipping audience checks. A valid signature from the wrong issuer is still the wrong issuer.
Related terms
OAuth 2.0 Authorization Code Flow
The standard delegation flow where users approve access on the provider and the app exchanges a short-lived code for tokens server-side. BYOB-managed Google sign-in hides this handshake from project developers entirely.
Refresh Token Rotation
The practice of issuing a fresh refresh token with every access-token renewal and invalidating the old one. Stolen tokens then expire quickly, and reuse of a spent token signals compromise.
Session vs Token Authentication
Server sessions store state behind an opaque cookie, while tokens carry signed claims the client presents each request. BYOB apps typically delegate both models to managed auth rather than hand-rolling stores.
Better Auth
Authentication with managed Google sign-in or email/password flows provisioned for generated apps. Auth pages (callbacks, sign-in) are private surfaces and stay noindexed like any other.
Cross-Site Request Forgery (CSRF)
An attack that tricks a logged-in browser into submitting unwanted state-changing requests to a trusted site. SameSite cookies, anti-CSRF tokens, and origin checks break the forgery chain.
SQL Injection
An attack that smuggles database commands through unsanitized input into application queries. Parameterized statements and least-privilege database roles keep hostile input as data, never executable code.