JWT decoding is not JWT verification

A compact signed JWT normally contains a protected header, payload, and signature separated by dots. The header identifies information such as the signing algorithm and key identifier. The payload contains registered or application-specific claims. The signature binds the encoded header and payload to a key.

Base64URL makes binary or JSON data safe for a URL-oriented alphabet; it does not make claims secret. Anyone holding an ordinary signed JWT can decode its header and payload. Confidential claims require an appropriate encryption design or should not be placed in the token.

A decoder can check whether there are three segments, whether the first two decode as JSON, and whether selected values have familiar shapes. It can format NumericDate claims such as exp, iat, and nbf. These checks help debugging but operate on attacker-controlled data until verification succeeds.

An expiry timestamp in the future is not evidence of authenticity. Anyone can construct a new payload with a later timestamp. Likewise, an alg value is a request in an untrusted header, not permission to use any algorithm the token names.

The receiving service chooses an allowed algorithm, selects the correct trusted key, verifies the signature, and rejects algorithm or key confusion. It then validates the issuer and audience it expects, applies expiry and not-before rules with a deliberate clock-skew policy, and enforces required application claims.

Library defaults are not a replacement for an explicit validation policy. The service should know which issuers and keys it trusts before a request arrives, and key rotation should be handled without accepting arbitrary key locations supplied by an untrusted token.

Use a synthetic or already revoked token where possible. Decode it locally, compare issuer and audience values with configuration, inspect the algorithm and key identifier, and translate time claims. Then reproduce the request in a trusted development environment that runs the same verification rules as production.

Do not paste an active bearer token into chat, issue trackers, screenshots, analytics fields, or random websites. A bearer token can grant access to whoever possesses it, regardless of whether they understand its contents.

iat describes when a token says it was issued; it does not by itself impose a maximum lifetime. nbf means the token should not be accepted before a time, while exp marks the time after which it must not be accepted. A service may require additional claims or use stricter session rules.

The payload can also contain private names that only a specific system understands. A generic decoder cannot decide whether those claims are complete, current, authorized, or meaningful for the request being made.