Innomerc Learn
English is the default.
Identity & Access

JWT Explained

Inspect the header, claims and signature of a token—and see why decoding is different from trusting.

Foundational6 min explorationReviewed
My learningNot started

Choose your depth. Learn at your own pace.

Simple explanation

Understand it

A JSON Web Token is a compact way to carry claims between systems. A claim might identify a user or say when the token expires. Many JWTs are signed: the recipient can check whether the token was issued by a trusted signer and changed afterward.

A signature is not a locked envelope. In a typical signed JWT, the header and payload are encoded and can be read. Never assume the token hides personal information. Keep tokens out of public links and logs.

Technical explanation

Under the hood

A compact signed JWT has three base64url-encoded parts: header, payload and signature. A verifier must use an allowed algorithm and trusted key, verify the signature, and validate expected issuer, audience and relevant time claims. Merely decoding the payload does none of those checks.

JWT is a format, not a complete login or authorization protocol. The application decides which claims to require and what permissions they imply. Different token types must not be interchangeable; an identity token intended for a client is not automatically an access token for an API.

Practitioner explanation

Practitioner perspective

Plan key rotation, token lifetime, clock tolerance and revocation. Stateless verification trades per-request lookup for a window in which a previously issued token may remain valid. Short lifetimes and controlled refresh flows reduce that window but add operational requirements.

Audit validation failures and key-discovery behavior. Do not let an untrusted header choose an arbitrary key URL. Never log entire bearer tokens. A correctly validated token still requires object- and operation-level authorization at the API.

See the decision happen

Watch it work

A fictional, simplified model. Select a component to inspect it, or follow the steps in order.

Interactive Lab

How credentials are checked

See the difference between storage, proof, validation and authorization.

Steps1. Signed token 2. Trusted public key 3. Validated claims 4. Allowed response
Click a box or choose its name to learn what it means.
ClientReadyVerifierReadyCredential storeReadyResourceReadyClientReadyVerifierReadyCredential storeReadyResourceReady
Ready to traceJWT validation
Before you start · 4 stepsJWT validation

A readable token is not a trusted token; validate claims before authorization.

How to use this example

Select Next step to read at your own pace, or Animate step to watch one exchange. Nothing advances until you choose.

Inspect components & read every step
  • Client

    A program that asks another system for information or an action.

    Example: A shopping app requests a list of products from a service.

  • Verifier

    The system checking whether the presented proof is acceptable.

    Example: A sign-in service checks a submitted password against its stored password verifier.

  • Credential store

    Storage for authentication-related records. It should not hold passwords as readable text.

    Example: A service stores salted password hashes and account information.

  • Resource

    The information or action someone wants permission to use.

    Example: A private document or an account setting is a resource.

JWT validation

A readable token is not a trusted token; validate claims before authorization.

  1. Client Verifier: Signed token. The request includes a token, not its signing key.
  2. Credential store Verifier: Trusted public key. Resolve trusted verification material; this may be cached.
  3. Verifier Resource: Validated claims. Check issuer, audience and lifetime, then evaluate permissions.
  4. Resource Client: Allowed response. Only an authorized operation returns protected data.

Server session

An opaque cookie identifies server-side session state.

  1. Client Verifier: Session cookie. The browser sends an opaque session identifier.
  2. Verifier Credential store: Lookup session. The service reads the associated state.
  3. Credential store Verifier: User + expiry. Expiry and revocation affect the result.
  4. Verifier Resource: Identity context. Resource authorization is still required.

Password hashing

Use a password KDF such as Argon2id with a unique salt and suitable cost.

  1. Client Verifier: Password over TLS. The verifier receives the candidate in a protected connection.
  2. Credential store Verifier: Salt + KDF settings. Retrieve the stored salt, parameters and verifier.
  3. Verifier Credential store: Compare verifier. Compare computed and stored verifier safely; do not store plaintext.
  4. Verifier Client: Decision. Apply rate limits and additional factors where required.

Refresh token

Renewal is a separate credential flow, not an extension of an expired access token.

  1. Client Resource: Expired token. The resource rejects an expired access token.
  2. Client Verifier: Refresh credential. The client presents its refresh credential to the authorization server.
  3. Verifier Client: New access token. Issue a new token only after the refresh policy succeeds.
  4. Client Resource: Retry with token. The resource validates the new token and requested permissions.

API key

An API key is a credential with scope, expiry and revocation policy—not necessarily a user identity.

  1. Client Verifier: API key. The client presents a secret credential over TLS.
  2. Verifier Credential store: Lookup policy. Check status, expiry and configured permissions.
  3. Verifier Resource: Scoped caller. Authorize this operation under the credential’s policy.

Authorization failure

Authentication can succeed while the requested object remains forbidden.

  1. Client Verifier: Valid credentials. The verifier establishes who the caller is.
  2. Verifier Resource: Other user’s object. The application checks the target owner and action.
  3. Resource Client: 403 · denied. Protected content is not returned.

Fictional teaching trace. One moving dot represents an exchange, not a measured network capture.

Open the detailed lesson walkthrough

Explore the system

Issue

A trusted service signs header and claims.

1 / 4

Takeaway A valid token reaches a separate permission decision.

Read every step without animation

Valid token

  1. Issue. A trusted service signs header and claims.
  2. Transport. The client sends the token to its intended API over TLS.
  3. Verify. The API checks signature, issuer, audience and lifetime.
  4. Authorize. The API checks permission for this specific resource.

A valid token reaches a separate permission decision.

Changed claim

  1. Issue. A token was signed with the user’s original claims.
  2. Alter payload. A claim is changed without the signing key.
  3. Verify. The signature no longer matches the protected data.
  4. Reject. The API rejects this modified token.

Decoding a changed claim does not make it authentic.

Explore deeper: additional experiment
Change an input. Inspect the consequence.

Decoding is not verification

Validation passed authorize

Signature, expected audience and lifetime pass this simplified model. Real implementations also check issuer and applicable claims, then enforce operation and object permissions.

A local teaching model with fictional inputs. It does not test a live system.

Attack view

The visual changes a claim after issuance. Signature verification rejects the modified token when the verifier uses the original trusted key and expected algorithm.

Defender view

  • Pin allowed algorithms and validate issuer, audience and time claims.
  • Use TLS and storage appropriate to the application’s threat model.
  • Apply resource authorization after token verification.

Common mistakes

  • Base64url is encoding, not encryption.
  • JWT payload claims are untrusted until verification and validation succeed.

Check your understanding

What does decoding a JWT establish?
Active recall: explain this idea in 30 seconds

A JSON Web Token is a compact way to carry claims between systems. A claim might identify a user or say when the token expires. Many JWTs are signed: the recipient can check whether the token was issued by a trusted signer and changed afterward.

Now give an example and name one limitation. Revisit the explanation if you get stuck.

Primary sources

Original explanations informed by these specifications and official resources. Source versions and lesson review are separate from product updates.

Content reviewed 2026-09-10. Read the editorial policy.

What comes next?

Web and application security
From passwords to identity security
Professional reference

Back to topic