Module 03 · Lesson 4 of 12Free

JWT: stateless authentication tokens

Level

Beginner

Topic

Authentication, authorization and security

Reading time

15 min

Mina logs out of Kartly at 10:02. A copied login token still opens her orders at 10:03, although every server reports that logout succeeded.

For this lesson’s scenario, the token expires at 10:05. How can a server trust a token without looking up a session, and what does that mean for logout?

The token carries the evidence

With the session design from the previous lesson, the client carries an identifier. The server looks up what that identifier means.

A JSON Web Token, or JWT, can instead carry signed statements called claims. This lesson uses signed JWTs, not encrypted JWTs. A signature protects their contents against undetected changes; it does not hide them.^{1JSON Web Token (JWT)Michael B. Jones, John Bradley, Nat Sakimura, RFC 7519, IETF, 2015}

The compact signed form has three dot-separated parts: a base64url-encoded header, an encoded payload and an encoded signature. Base64url is a reversible encoding, not encryption.^{1JSON Web Token (JWT)Michael B. Jones, John Bradley, Nat Sakimura, RFC 7519, IETF, 2015}

Here are illustrative decoded contents, not a usable credential:

{
  "alg": "ES256",
  "typ": "JWT",
  "kid": "kartly-key-a"
}

{
  "iss": "https://auth.kartly.example",
  "sub": "customer_42",
  "aud": "kartly-api",
  "iat": 1800000000,
  "exp": 1800000300
}

Kartly’s proposed token contract uses these fields:

The time fields use seconds since the Unix epoch. The example lifetime is 300 seconds. JWT defines these claim names, but applications must decide which claims they require.^{1JSON Web Token (JWT)Michael B. Jones, John Bradley, Nat Sakimura, RFC 7519, IETF, 2015}

Do not put passwords or delivery addresses in this token. For Kartly’s order endpoint, a customer identifier is enough. Extra personal data would travel with every request without helping identify its owner.

The next question is whether moving this evidence into the client solves a problem Kartly actually has.

Local checks replace session lookups

Kartly is at the course’s few-server stage. For this scenario, it runs three app servers behind a load balancer.

A shared session store already lets all three recognize Mina. JWTs are therefore an alternative, not a prerequisite for adding servers.

For the rest of the lesson, assume Kartly is evaluating that separate API. This is a proposed design, not a claim that its existing sessions need replacement.

Its first task is separating permission to issue tokens from permission to verify them.

Verification does not require signing power

A shared-secret method, such as HS256, gives the issuer and verifier the same secret. Anyone able to verify with that secret can also create tokens. A public-key method separates those capabilities: the issuer signs with a private key, and APIs verify with its public key.^{3JSON Web Token Cheat SheetOWASP Cheat Sheet Series contributors, OWASP Cheat Sheet Series, 2026}

For this proposed design, Kartly chooses ES256. Only the login component holds the private key. The API servers receive public keys.

This boundary matters if an API server is compromised. Possessing its verification key alone must not let an attacker issue new customer identities. It does not protect customer data already accessible on that compromised server.

A shared secret remains an option when one tightly controlled application both issues and verifies tokens. It has fewer distinct key roles to manage. Here, separate issuance is the requirement that justifies the key pair.

These are logical responsibilities. The login component can remain inside Kartly’s application deployment.

Issuing and using one token

The proposed write path is:

1. The login component verifies Mina’s credentials.
2. It creates the required claims from trusted account data.
3. A JWT library signs the encoded header and payload.
4. The client receives the token over HTTPS.

The protected read path is:

1. The client sends its token through the load balancer.
2. The selected app server validates it.
3. The order handler uses the validated customer identifier.
4. PostgreSQL returns only that customer’s orders.

The app server still needs authorization checks. A valid identity does not grant access to every order.

Local authentication removes one dependency from this path. It does not make the database or application stateless.

Decode first, trust only after validation

Kartly’s proposed API contract presents the token as a bearer credential: possession is enough to use it. A stolen copy can therefore be replayed.^{3JSON Web Token Cheat SheetOWASP Cheat Sheet Series contributors, OWASP Cheat Sheet Series, 2026}

GET /v1/orders HTTP/1.1
Host: api.kartly.example
Authorization: Bearer <signed-token>

The app server’s authentication middleware owns validation. Configure a maintained JWT library with this policy rather than implementing signature verification yourself:

Algorithm restrictions, issuer validation and audience validation prevent distinct classes of token substitution. A token’s own header must not decide what algorithms or issuers the application trusts.^{2JSON Web Token Best Current PracticesYaron Sheffer, Dick Hardt, Michael B. Jones, RFC 8725, IETF, 2020}

In particular, kid is a lookup hint, not a source of trust. Kartly’s middleware looks it up in its configured key map. It never downloads a key from an arbitrary location supplied by the token.^{3JSON Web Token Cheat SheetOWASP Cheat Sheet Series contributors, OWASP Cheat Sheet Series, 2026}

Suppose someone edits sub to another customer. The payload changes, so signature verification fails. But a correctly signed token for a different API also needs rejection: its audience does not match Kartly’s policy.^{1JSON Web Token (JWT)Michael B. Jones, John Bradley, Nat Sakimura, RFC 7519, IETF, 2015}

Kartly’s endpoint contract returns 401 for missing, invalid or expired credentials. After successful authentication, it returns 403 when an operation is forbidden. Verification infrastructure failures produce a temporary server error, not a successful request.

Successful validation establishes what the issuer said. It cannot establish that those statements remain current.

Expiration sets the stale-information window

Assume Kartly issues a token at 10:00 with a five-minute lifetime. At 10:02, support disables Mina’s account.

Under purely local validation, the app server has no new information about that change. It still sees a correctly signed, unexpired token. This follows directly from the proposed design’s inputs.

The peak request rate comes from Kartly’s example-world stage. The protected fraction and token lifetime are illustrative choices. Neither establishes that signature verification will be faster; Kartly would measure both designs.

Short lifetimes also require a renewal plan. A refresh token is a separate credential used to obtain another access token. In a proposed Kartly design, the login system would store its status and refuse renewal after logout. That would stop new access tokens, not invalidate old ones.

Renewal therefore moves state away from some requests; it does not remove state from login.

Key changes create operational boundaries

For planned rotation, Kartly can first distribute a new public key, then begin signing with its matching private key. It retains the old verification key until tokens signed with it can no longer pass its time policy.

Removing the old key earlier would reject customers whose tokens still have time remaining. This is a consequence of Kartly’s key-selection design.

For this proposal, monitor rejection reasons separately: bad signature, wrong audience, expiration and unknown key. Never include full credentials in logs. A sudden unknown-key increase after deployment points toward inconsistent configuration, not necessarily stolen accounts.

If no trusted key can verify a request, reject it. Do not bypass verification to restore availability.

Common mistakes

• “JWT means encrypted.” Signed claims remain readable. Keep secrets out of them.^{3JSON Web Token Cheat SheetOWASP Cheat Sheet Series contributors, OWASP Cheat Sheet Series, 2026}
• “Valid signature means valid request.” Issuer, audience and application permissions still matter.^{2JSON Web Token Best Current PracticesYaron Sheffer, Dick Hardt, Michael B. Jones, RFC 8725, IETF, 2020}
• “Deleting the browser copy logs out every copy.” Under Kartly’s local policy, other copies survive until expiration or a shared rejection rule applies.
• “Roles inside the token are current.” In this design they describe issuance-time information. Recheck current permissions where delayed changes are unacceptable.

Where this shows up

• Design: login and single sign-on: coordinates issuance, renewal and logout across applications.
• Design: a payment processing system: must distinguish authenticated identity from permission to move money.

Kartly can now verify its own issuer’s tokens; OAuth 2.0 and OpenID Connect asks how login works when another organization supplies the identity.

Check your understanding

Summary