How Does JWT Authentication Work?You've probably seen something like this when working with APIs: Authorization: Bearer eyJhbGciOi... It looks complicated.But what is it?That long string is often a:JWT — JSON Web TokenJWTs provide a compact way of transmitting claims between parties. A JWT can be digitally signed so the recipient can verify that the token has not been modified.A common API flow is:User logs in↓Server verifies credentials↓Server issues token↓Client sends token with API requests↓Server verifies token↓Access grantedThat's the basic idea.What Does JWT Stand For?JWT means:JSON Web TokenIt is defined by RFC 7519 and represents claims in a compact JSON-based format.A JWT commonly looks like: xxxxx.yyyyy.zzzzz There are three parts:HeaderPayloadSignatureWhat Is Inside a JWT?A JWT has three sections separated by dots: HEADER.PAYLOAD.SIGNATURE For example: eyJhbGciOiJIUzI1NiJ9 . eyJzdWIiOiIxMjM0NSIsImV4cCI6MTc... . SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c Don't worry about memorizing the characters.The important part is understanding the three sections.1. JWT HeaderThe header contains information about the token, such as the signing algorithm and token type.Conceptually: { "alg": "HS256", "typ": "JWT" } The alg value indicates the algorithm used for signing.2. JWT PayloadThe payload contains claims.For example: { "sub": "12345", "role": "student", "exp": 1780000000 } These claims can communicate information about the token subject and its validity.Common registered claims include:sub — subjectiss — issueraud — audienceexp — expiration timeiat — issued-at timeJWTs can also contain application-specific claims.3. JWT SignatureThe signature is what allows the receiving system to verify that the signed token hasn't been altered.Depending on the algorithm, JWTs can use:A shared secretA public/private key pairFor example, JWT supports HMAC-based signing as well as RSA and ECDSA-based signatures.The key idea is:A valid signature does not mean the information is secret. It means the token can be authenticated as having been signed by the expected party and its signed contents have not been modified.Is JWT Encrypted?This is one of the biggest JWT misconceptions.A normal signed JWT is not automatically encrypted.Its contents can generally be decoded by anyone who obtains the token.The signature protects integrity/authenticity, not confidentiality. JWT can also be encrypted in other configurations, but a normal signed JWT should not be treated as a secret container.Therefore:Don't put this inside a normal JWT:❌ Passwords❌ Credit-card numbers❌ Private keys❌ Sensitive personal information❌ Database secretsA good rule is:If the user should not be able to read it, don't put it in an ordinary signed JWT.How Does JWT Authentication Work?Let's take a real example.Imagine a student logs into an online learning platform.Step 1 — LoginThe student enters: Email Password The browser sends the login request to the backend over HTTPS.Step 2 — Server Verifies CredentialsThe backend checks whether the credentials are valid.If they are correct, the server can issue an access token.Step 3 — JWT Is IssuedThe server creates a signed JWT containing appropriate claims.For example: { "sub": "student_123", "role": "student", "exp": "..." } The client receives the token.Step 4 — Client Requests Protected DataThe student now wants to access: GET /api/my-courses The request can include: Authorization: Bearer The JWT specification's introduction describes this common Bearer-token pattern for accessing protected resources.Step 5 — Backend Validates the TokenThe server checks things such as:Is the signature valid?Has the token expired?Is the issuer correct?Is the audience correct?Are the required claims present?Does the user have the required authorization?If the checks pass:Request allowedOtherwise:Request rejectedThe Complete JWT Flow USER ↓ Login ↓ Backend ↓ Verify Credentials ↓ JWT Issued ↓ Client ↓ Authorization: Bearer ↓ Protected API ↓ Verify JWT ↓ Access Granted This is the basic JWT authorization flow.JWT Authentication vs AuthorizationThese words are often mixed up.AuthenticationWho are you?Example:This user is Onkar / Student 123.AuthorizationWhat are you allowed to access?Example:Student 123 can access their courses but cannot access the admin dashboard.JWTs can carry claims that help with authorization, but the overall authentication and authorization architecture depends on how the application uses the token.The JWT specification itself describes authorization as a common JWT use case.What Is an Access Token?An access token is used to access protected resources.For example: GET /api/profile Authorization: Bearer Access tokens are generally designed to have a relatively limited lifetime.If the token expires, the client needs another valid authorization mechanism to obtain a new access token.What Is a Refresh Token?A refresh token is used to obtain a new access token without requiring the user to enter their credentials again.A simplified flow is: Login ↓ Access Token + Refresh Token ↓ Access Token expires ↓ Refresh Token used ↓ New Access Token Refresh tokens are highly sensitive credentials and require careful lifecycle management. Current OAuth security guidance emphasizes measures such as refresh-token rotation and replay detection for applicable public clients.So don't think:"Refresh token = permanent login."It still needs secure handling, expiry/lifecycle policies and revocation strategy.Where Should JWT Be Stored?This is a surprisingly important question.There isn't one universal answer for every application architecture.For browser applications, developers need to carefully consider risks such as XSS, CSRF, token theft and cookie configuration.The JWT project itself warns that tokens are credentials and should be handled carefully, and specifically cautions against storing sensitive session data in browser storage.For browser-based applications, secure cookie-based designs using appropriate:HttpOnlySecureSameSitesettings can be part of a safer architecture, depending on the application.The important lesson is:Don't copy a token-storage pattern from a random tutorial without understanding its security implications.Is JWT Better Than Sessions?Not automatically.This is another common misconception.A JWT and a traditional server-side session solve similar broad problems but use different architectures.Session-based authentication Browser ↓ Session ID ↓ Server ↓ Session Store The server maintains session state.JWT-based approach Browser / App ↓ JWT ↓ Server ↓ Verify Token The token carries signed claims that the server can validate.JWTs can be useful for distributed APIs and systems where independently validating tokens is valuable, while traditional sessions can provide simpler server-side control and revocation. Current technical discussions emphasize that the right choice depends heavily on application architecture rather than JWT being universally superior.When Is JWT Useful?JWTs can be particularly useful in systems involving:REST APIsClient applications can present access tokens to protected API endpoints.Mobile applicationsA mobile application can authenticate against a backend API and use access tokens for subsequent requests.MicroservicesA service can validate a token's signature and claims without necessarily contacting a centralized session store for every request.Distributed systemsMultiple services can use a common trust model for validating tokens.Machine-to-machine communicationTokens can represent authorization between services.JWTs are used in real production systems; for example, Fermilab has documented a transition to token-based authentication using JWT access tokens across parts of its computing infrastructure.REAL-WORLD / COMPANY PROJECT PERSPECTIVENow let's make this practical.Imagine your company is building:An Online Learning PlatformThe system has: Student App ↓ API Gateway ↓ Authentication Service ↓ ┌────┼────┐ ↓ ↓ ↓ Course User Payment API API API A student logs in once.The authentication system issues an access token.The application can then send the token when requesting protected resources.For example: GET /api/courses Authorization: Bearer The API gateway or backend service validates the token.Then: Valid JWT ↓ Check claims ↓ Check permissions ↓ Allow request This is a real backend architecture problem—not simply a programming exercise.Example: Student vs AdminSuppose your platform has:Student role = student Instructor role = instructor Admin role = admin A student requests: GET /api/my-courses The server checks the token and allows access.But the same student requests: DELETE /api/course/123 The backend should check authorization and reject the request if the student does not have permission.This demonstrates an important principle:Having a valid JWT does not automatically mean the user can do everything.Authentication and authorization still need to be designed correctly.What Happens If Someone Changes the JWT?Suppose an attacker obtains: { "role": "student" } and changes it to: { "role": "admin" } Would that automatically work?No—if the server correctly validates the signature.The attacker cannot simply change the signed claims and produce a valid signature without the appropriate signing secret/private key.That's one of the fundamental purposes of the JWT signature.But developers must still validate:SignatureAlgorithmIssuerAudienceExpirationRequired claimsAuthorization rulesJWT Does Not Replace HTTPSRemember our previous article:Blog 11How Does HTTPS Work?HTTPS/TLS protects communication between the client and server.JWT provides signed claims that the application can use for authentication/authorization.They solve different problems.A simplified secure architecture is: Client ↓ HTTPS / TLS ↓ Backend API ↓ JWT Validation ↓ Authorization ↓ Database So:JWT + HTTPSis much more meaningful than thinking of JWT as a replacement for HTTPS.Common JWT Mistakes1. Putting passwords inside JWTDon't.2. Assuming JWT is encryptedA normal signed JWT isn't.3. Making tokens live foreverLong-lived credentials increase the impact of token theft.4. Ignoring expirationValidate the exp claim where applicable.5. Trusting the role without validating the tokenNever simply decode a JWT and trust its contents.6. Storing tokens carelesslyToken storage is part of the security architecture.7. Forgetting revocationJWTs can be difficult to invalidate immediately if your architecture doesn't include an appropriate revocation/lifecycle mechanism.8. Putting too much data into the tokenJWTs travel with requests and can become unnecessarily large. The JWT specification's official introduction also cautions against putting sensitive information into ordinary signed tokens.JWT in One Simple ExampleImagine:Login POST /login ↓Server verifies credentials↓Server returns JWT eyJhbGciOi... ↓Client requests: GET /profile Authorization: Bearer eyJhbGciOi... ↓Server verifies:Signature ✓Expiration ✓Issuer ✓Audience ✓↓Server checks permission↓Profile returnedThat's JWT in practical terms.Frequently Asked QuestionsWhat is JWT?JWT is a compact JSON-based token format defined by RFC 7519. It can carry claims and can be digitally signed for integrity and authenticity.How does JWT authentication work?A user authenticates, the server issues a signed token, the client sends the token with protected requests, and the server validates the token before allowing access.Is JWT encrypted?Not by default. A signed JWT provides integrity/authenticity, while encryption is a separate capability.Is JWT secure?JWT can be used securely, but security depends on correct implementation, including signing-key management, validation, expiry, token storage and authorization.What is an access token?A credential used by a client to access protected resources.What is a refresh token?A credential used to obtain new access tokens without requiring the user to authenticate again, subject to the application's security design.Should JWT be stored in localStorage?There is no universal "yes." Browser token storage involves security trade-offs, particularly around XSS and token theft. Secure cookie-based approaches are often considered for browser applications, depending on the architecture.What is JWT vs session authentication?JWT-based systems commonly carry signed claims with the client, while session-based systems generally keep authentication state on the server and give the client a session identifier. Neither is universally better.Can JWT be used with HTTPS?Yes. In fact, HTTPS/TLS and JWT address different security requirements and can be used together.Can someone modify a JWT?Someone can modify the encoded contents, but a correctly implemented server should reject a modified token because its signature will no longer validate.Does JWT replace a database?No. JWT can carry claims and reduce the need for some session lookups, but applications still need databases for users, courses, orders, permissions and other persistent data.Why This Skill Matters in a CompanyUnderstanding JWT is useful when you're:Building REST APIs→ Protect endpoints.Developing mobile applications→ Authenticate API requests.Building SaaS platforms→ Manage authenticated users and permissions.Working with microservices→ Pass verifiable authorization information between services.Building admin dashboards→ Control role-based access.Working in DevOps/cloud→ Understand authentication between distributed services.Working in cybersecurity→ Analyse token validation, expiry, storage and authorization vulnerabilities.Developing full-stack applications→ Connect frontend authentication with backend authorization.This is why JWT isn't just an interview question.It is a concept you'll encounter when building real APIs and distributed applications.
