What Is JWT? How JSON Web Token Authentication Works

What Is JWT and What Is It Used For?

JWT (JSON Web Token) is an open standard that carries claims about a user or system between two parties as a compact, URL-safe, signed string. The receiving server verifies the signature, so it knows nobody changed the content in transit. Specifically, the IETF defines the format in RFC 7519.

Think of a JWT as a sealed entry badge. It also shows your name, your permissions, and an expiration time. So the guard at the door does not need to know you personally. If the seal is genuine, the guard lets you in, and if someone tampered with the badge, the seal breaks.

That is why teams use JWT in systems where several parts talk to each other, such as a web interface, a mobile app, and an API. After you sign in, the token answers the question "who am I and what may I do" on every later request. As a result, the server can check the answer without a database lookup each time.

However, JWT is not a security shortcut. Set up correctly, it is a practical transport format. Otherwise, it creates quiet vulnerabilities. In this guide we walk through the structure, the flow, the risks, and a checklist, all at a conceptual level.

Readers who ask what is JWT usually fall into two groups. Some are new developers who want to understand the word "token." Others are technical teams reviewing an existing system. We start with a simple definition and then add depth for both.

What Is JWT in Plain Language, Using an Everyday Example?

Picture a sealed, transparent envelope. Anyone can read the letter inside, because the envelope is clear. The seal, however, belongs only to the organization that issued it, and nobody else can copy it. If someone edits the letter, the seal breaks and you notice right away.

Likewise, a JWT works the same way. Anyone who holds it can read its content, so the content is not secret. Instead, the secret part is the key that produces the signature. This difference matters a lot, because the most common beginner mistake is assuming that a JWT is encrypted.

For example, an event ticket carries information about you, and the staff checks it at the gate. The staff can also confirm the ticket by calling headquarters with the ticket number, or by inspecting its seal. The first method resembles a session cookie, and the second resembles the JWT approach.

What Is JWT Used For in Real Systems?

Example scenario: a retail business runs a mobile app, a web store, and a stock panel, all with the same user account. When a customer signs in once, an identity service issues a signed token. The order service then verifies that token without asking the identity service. As a result, the services depend on each other less, and the system grows more easily.

• Single sign-on (SSO): A user signs in once and moves between several applications.
• API access: Web and mobile clients attach a token to every request.
• Service-to-service identity: Microservices tell each other who they are with a token.
• Short-lived, single-purpose actions: For instance, carrying the validity information of a verification link.

In short, the practical answer to what is JWT used for is this: it is the standard way to carry identity and permission information between two parties safely. Still, it is not the right pick for every case, as the later sections show.

What Are the Header, Payload, and Signature of a JWT?

First, a JWT has three parts, and dots separate them. Conceptually, the shape looks like "header.payload.signature." The system writes each part in base64url, a URL-safe encoding. Encoding is not encryption, so anyone can decode it back to readable text.

• Header: A small JSON object that names the token type and the signing algorithm.
• Payload: A JSON object that carries the claims, meaning information about the subject and the use of the token.
• Signature: A value that proves integrity, produced by signing the header and payload with a key.

Then the server recalculates the signature and compares it with the one it received. If they do not match, someone changed the header or the payload, and the server rejects the token. Put simply, all the security rests on that comparison. Therefore, a system that skips signature verification gets none of the benefit of JWT.

Also, the algorithm named in the header is not a source of trust by itself. We cover that in the security sections below.

Note: We deliberately do not show a realistic-looking token in this article. To grasp the structure, the three-part scheme is enough.

What Are Claims in a JWT Payload?

In other words, a claim is a single statement about the token or its subject. RFC 7519 defines a few standard (registered) claim names. All of them are optional, but most systems also use several. That way, different applications mean the same thing when they use the same word.

• iss (issuer): Says who produced the token.
• sub (subject): Says who the token is about, usually the user identifier.
• aud (audience): Says which service the token is meant for.
• exp (expiration time): Says when the token stops being valid.
• nbf (not before): Says the moment before which nobody should accept the token.
• iat (issued at): Says when the token was created.
• jti (JWT ID): Gives the token a unique identifier, which helps track reuse.

You can also add your own custom claims, such as a user role. Keep the payload small, though, because the token travels with every request. Moreover, do not store sensitive data in custom claims, and the section on sensitive data explains why.

How Does a JWT Signature Work, and Why Verify It on Every Request?

First, there are two main ways to sign. The first uses a shared secret with a message authentication code (for example, HMAC). Both the party that issues the token and the party that verifies it know the same secret. Asymmetric signing is the second way: the issuer signs with a private key, and verifiers only use the public key.

For example, in a small, single-service app, a shared secret can be enough. With several services, asymmetric signing is more comfortable, because the verifying services cannot create signatures. As a result, if attackers take over one service, they still cannot mint tokens for the whole system.

You must verify on every request, because seeing a token once does not make it trustworthy forever. Also, someone may have copied it from a device, a network path, or a log file. So you repeat the signature, expiration, and audience checks every time. In practice, skipping these checks in sensitive steps such as account changes or payments is the costliest mistake.

Why Do Key Management and Key Rotation Matter?

First, if the signing key leaks, anyone who holds it can produce valid tokens in your name. Therefore, never keep the key in a code repository, a client app, or a plain text settings file. Instead, use a store built for secrets, and limit who can read it.

Replacing keys on a regular schedule, called key rotation, is also a good habit. A key identifier in the token header (kid) tells the verifier which key signed the token. During a transition, the verifier then accepts both the old and the new key. For publishing public keys, the JWK and JWKS formats exist.

One warning applies here, though. Even when the header points to a key source, do not trust it blindly. OWASP lists "trusting key material named in the token header" as a separate threat. Define your trusted key sources on the server in advance.

What Is the Difference Between JWS and JWE?

Specifically, a JWT does not carry its claims alone. It rides inside one of two structures. JWS (JSON Web Signature, RFC 7515) signs the claims. JWE (JSON Web Encryption, RFC 7516) encrypts them. So when people casually say "JWT," they usually mean the signed JWS form.

A signed JWT gives you integrity and origin proof, but the content stays readable. On the other hand, an encrypted JWT hides the content from everyone without the right key. Consequently, if the payload must hold a secret, a signature is not enough. Either leave that information out or use the encrypted form.

A nested JWT combines both, for example signing first and encrypting second. Still, in most business applications the best path is simpler: keep the payload small so it never needs to hold sensitive data. Moreover, that design stays easier to build and produces fewer bugs.

What Is JWT Compared With a Session Cookie, and Which Should You Pick?

First, with a traditional session cookie, the server keeps a record for each signed-in user. Meanwhile, the browser only receives a meaningless session number. With JWT, the information lives inside the token, so the server often keeps no record. Both models have real strengths and weaknesses.

Do not conclude from the table that JWT is always more modern. The OWASP JWT Cheat Sheet is openly cautious about recommending JWT for stateless user sessions. The reason is that logout and revocation also call for server-side state. For a simple website, a well-managed session cookie is often safer and less work. So what is JWT worth there? Often less than a well-run cookie session.

How Do Access Tokens and Refresh Tokens Work Together?

In practice, teams use two tokens instead of one long-lived token. The client sends the access token to the API, and it lives for a short time. Meanwhile, the refresh token only serves to obtain a new access token, and it lives longer. As a result, this split limits the damage when someone steals an access token.

1. First, the user signs in with credentials or a passkey.
2. Then the identity server issues an access token and a refresh token.
3. Next, the client attaches the access token to API requests.
4. After that, the API rejects the request once the access token expires.
5. Then the client sends the refresh token to the identity server and receives a new access token.
6. Finally, when the user signs out or something looks suspicious, the identity server revokes the refresh token.

The key point is that the server can track the refresh token. As a result, you can revoke it, count its uses, and close the whole chain when you see signs of theft. We therefore do not fix lifetime values as numbers here. Set them according to your risk level and check current guidance.

Which Checks Should a Server Run Before Accepting a JWT?

In practice, verification is more than a single "signature OK" check. RFC 8725 (best current practices for JWTs) and the OWASP documents recommend several checks together. If one is missing, however, a token can look valid and still be accepted in the wrong place.

1. Confirm the token has the three-part structure and decodes cleanly.
2. Pin the expected signing algorithm on the server instead of following the token header.
3. Then verify the signature with the correct key.
4. Also check the time window with exp and nbf.
5. Confirm that iss names an issuer you trust.
6. Confirm that aud includes your service.
7. Check that the token carries the needed permission, and make the real authorization decision on the server.

In short, the signature says "nobody changed this token." The other checks answer "is this token valid now, here, and for this job." When you run all of them, JWT becomes a dependable carrier.

Where Should You Store a JWT in the Browser?

Storage is the most debated topic in JWT security. Still, no single answer fits everyone, and the risks are clear. A token in a place that page scripts can read may be stolen if malicious code reaches the page (XSS). Cookies bring a different problem: the browser sends them automatically, so you need separate protection against forged requests (CSRF).

For tokens that live in the browser, many teams choose a cookie with the HttpOnly, Secure, and suitable SameSite attributes, because scripts cannot read it. The MDN cookie documentation is a good primary source for these attributes. In mobile apps, you instead use the secure storage of the operating system.

Whichever path you choose, two principles apply. First, you must close XSS holes, because no storage method gives full protection when one exists. Second, keep the access token short-lived to reduce the effect of a leak. For the wider web security picture, read our OWASP Top 10 guide.

What Are the Most Common JWT Security Mistakes?

In practice, the mistakes teams see most often are surprisingly simple. Moreover, most of them come from how people use the library, not from the library itself. The list below sums up where to look first during a review.

• Keeping sensitive data in the payload, even though the payload is not encrypted.
• Never verifying the signature, or decoding the token and trusting the content.
• Letting the token choose the algorithm, and mixing up key types.
• Issuing tokens that never expire or live far too long.
• Storing the token where page scripts can read it.
• Skipping the iss and aud checks.
• Never designing the logout and revocation scenario.
• Placing the signing key in the code repository, in logs, or on the client side.

Next, we cover each of these in the sections that follow. If you want a wider view of access problems, our guide to the 401 Unauthorized error adds useful context.

Why Should You Never Put Sensitive Data in a JWT Payload?

First, the payload is only encoded, not encrypted. As a result, anyone who gets the token can read it without any key. That person may be an attacker, but it may also be a proxy, a logging system, or a browser extension that the token passes through.

Therefore, passwords, card details, health information, full addresses, and national ID numbers do not belong in the payload. In practice, a user identifier, a role, and an expiry time are usually enough. For everything else, the server then looks up the user in its own database.

In systems that handle personal data, this is also a compliance matter. Also, the data minimization principle says to avoid carrying data you do not need. This article is not legal advice. Read our GDPR-compliant website guide and consult your legal adviser.

What Happens When Signature Verification Fails or the Algorithm Gets Confused?

First, if a system never verifies the signature, the token is just plain text that anyone can edit. Scenarios such as changing a role or writing another user's identifier then become possible. This mistake often slips in when a quick prototype goes live, because someone assumed that decoding was enough.

However, algorithm confusion is subtler. The token header names the algorithm that signed it. If the server follows that hint blindly, an attacker can push the server toward a method it never meant to accept. The standard also describes an unsecured JWT form. It exists only for special cases with a guarantee outside the signature, and you should never accept it for user sign-in.

In short, the defense is straightforward. Define the accepted algorithms as a fixed list on the server, match the key type to the algorithm, and use a well-maintained, current library. For the official recommendations, study RFC 8725.

How Do You Handle Token Expiration and Revocation?

A signed JWT stays valid until it expires, and by default the server cannot "call it back." For this reason, a token without an expiry is the most dangerous choice: once stolen, it works forever. Every token should carry an expiration time, and the access token should keep it short.

Still, sometimes you must invalidate a token early. For example, a user may sign out, change a password, or close an account. The OWASP document lists the main approaches: keep a denylist of revoked tokens, use a token status list, and track refresh tokens on the server.

The dream of a fully stateless system therefore clashes with the need for instant revocation. Most real applications strike a balance: a short-lived access token, a tracked refresh token, and extra verification for critical actions. If you need very strong revocation, a server-side session model is the more honest solution.

How Do Token Size and Performance Affect Your App?

First, a token travels with every request. Consequently, the more claims and permission lists it holds, the heavier each request becomes. That raises network traffic and may hit header size limits in some servers or intermediate layers. Stuffing every permission into the token is usually a poor idea.

A better approach keeps only the basics in the payload, such as the identifier, the role, and the expiry. You then query detailed permissions on the server by user identifier. That way, a permission change takes effect right away, and the token stays small.

The processor cost of signature verification is usually lower than the cost of a database round trip on every request. Even so, do not decide without measuring. Run a load test on your own system and let the results guide you.

How Do JWT, OAuth 2.0, and OpenID Connect Relate?

Many people mix up these three terms, yet they sit on different layers. JWT is a data format. OAuth 2.0 is an authorization framework that lets an application get limited access to another service on your behalf. OpenID Connect is an identity layer built on top of OAuth 2.0, and it tells the application who the user is.

In a "sign in with Google" flow, for instance, OpenID Connect runs behind the scenes and the ID token arrives as a JWT. Learning JWT is therefore a basic step toward reading modern identity systems. The "token" in AI pricing is a completely different idea, so if the terms confuse you, read our guide on what a token is in AI.

What Is the Difference Between JWT and a Passkey?

A passkey is a way to prove who the user is. It replaces the password with a private key on the device plus biometric or PIN confirmation. A JWT, on the other hand, carries the result of that proof to later requests. One answers "how do I prove who I am," and the other answers "how do I carry that proof."

These two technologies are not rivals, and they often work together. The user signs in with a passkey, and after a successful sign-in the server issues a short-lived token or a session. To learn passkeys in depth, read what a passkey is.

Example scenario: in a mobile app, the user signs in with a passkey. The app then receives a short-lived access token in the background. Sign-in is passwordless, but the token still carries the identity between requests.

When Is JWT the Right Choice, and When Is It Not?

The strong cases are clear: several services verifying the same identity independently, mobile and API communication, short-lived permission transfer, and single sign-on. In such systems, not having to connect every service to a shared session store is a big convenience.

• A good fit: Service-to-service identity, short-lived API access, federation, and SSO.
• Handle with care: Long user sessions, permissions that must end instantly at sign-out, and large payloads.
• Possibly unnecessary: A classic website on a single server, or a simple admin panel.

If a REST or GraphQL API sits behind your tokens, review your API design too. Our article on GraphQL versus REST offers the relevant perspective. Real-time connections need their own authentication thinking, and our WebSocket guide points the way.

What Should Your JWT Security Checklist Include?

Once you know what is JWT and how it fails, turn that knowledge into action. The list below gathers the points to review before a project goes live. Everything stays at a conceptual level, so confirm detailed values in the current documentation of your provider and the standards.

• Do I verify the signature on every request?
• Did I pin the accepted algorithms on the server?
• Do the signing keys live in a secure secrets store?
• Does every token have an expiry, and is the access token short-lived?
• Do I check both iss and aud?
• Does the payload hold only the minimum needed, with no sensitive data?
• Can I track and revoke refresh tokens when needed?
• Did I design sign-out, password change, and account closure?
• Did I store the token where page scripts cannot read it?
• Does all traffic run over HTTPS?

For the last item, you can test your certificate with our SSL checker and read the basics in our SSL certificate guide. After all, a signature does not protect a token that travels over an unencrypted connection.

How Should You Approach JWT in a Custom Software Project?

Example scenario: a business plans a system with a web interface, a mobile app, and an internal admin panel. All three will use the same backend services. Our team starts such projects with one question: in how many places will we verify identity and permissions, and how fast must revocation be?

The answer changes the decision. For one web application, a solid cookie session may be enough. With several clients and services, a short-lived access token and a tracked refresh token fit better. To see where this logic sits on the server side, read what backend development is.

Authentication is among the most critical parts of a product, so do not treat it as a patch to add later. Our team recommends settling this decision during the architecture phase. If you would like to plan such a project with us, take a look at our custom software development service.

Final word: what is JWT in the end? An excellent tool, but a tool is only as secure as the way you use it. Reading the standard (RFC 7519), the best practices document (RFC 8725), and the OWASP JWT Cheat Sheet regularly is the most reliable way to keep your knowledge current.