JWT Explained: How Stateless Authentication Actually Works | JWKS, RS256, Auth0

Añadido: 2026-05-06

[00:00:00]What if I told you that your server doesn't need a database to know who you are? No session table, no radius, no memory store, nothing. Just a single string that contains everything the server needs to authenticate you. That's the magic JWT JSON web token. In this video, you will learn exactly how JWT works under the hood. Why it is called stateless authentication. How it validate token from or zero, Firebase and other provider. and the RS 256 algorithm and why it matters. So first section we are covering uh so first thing is three parts of JWT header payload and a signature. header contains this thing algorithm type and key id payload contains the data I mean you can encode some data inside your JWT token and this is the signature using which it is created right so base 64 it's readable the user data you can decode it signature proves the token has been tempered or not and the expiry obviously we need to have some kind of a token expiry so that we can have a limited livveness of the token overall JWT token looks like a random string. The algorithm which we are using uh random string which has a three different parts. The header this is important part. Algorithm is RS256 or HS256. The type is always JWT and the key ID. K ID is the key ID. Part two is the payload where we it can the purple part this contains the actual user data. You can encode the user ID, org ID, email, whatever the information which API needs after validating the token signature.

[00:01:38]The blue part, this is the security layer. The server creates this by taking the header and payload and signing them with the secret key. This signature proves the token has not been tampered with. So this signature so you might have remember JWT JSON web token JWT. JWT.verify these methods in NodeJS. So this is my sample JWT token.

[00:02:02]I can paste my one also. Algorithm type.

[00:02:06]This is the payload decoded payload. And this is the secret.

[00:02:11]The earlier one also looks like this.

[00:02:13]This is the payload which we have. Okay.

[00:02:16]Anyone can decode this. This payload and header and payload are just B64.

[00:02:22]Critical point never put sensitive data like password all these information inside the decoded payload. I mean the information which we should put is just identifier user identifier or or ID email that's it okay not more than that now the thing is GWT is called a stateless or a stateful let's discuss about that you might have heard this term stateful and a stateless authentication the key difference is inside a stateful server stores the session in the DB radius every request you need to look up inside a database to validate okay this session an existing database hard to scale horizontally um the sessions in the distributed manner you need to have a radius cluster so that all the instance can can access the radius instance easy to invalidate that's a good thing that if you are managing sessions using radius uh or and database it's easy to invalidate all the login sessions of that user stateless GWT it which doesn't store anything on the server token contains all the user data you need easy to scale horizontally but it is hard to invalidate ate or kill the token which has been created. Right?

[00:03:32]So scaling comparison if you want to scale the the session based stateful need a shared store right like the radius or the database where if your application is uh across multiple lambdas multiple instances then you need a centralized cluster versus stateless you don't need because they have the secret key they can verify they can create the token so that is the big advantage of a stateful and a stateless authentication and token based is a stateless place token based authentication. The only part is the which is little difficult in the token based authentication is hard to invalidate the token on the log out. So what actually happens in the token based authentication you log in you receive a JWT token. Now you just send a JWT token in the API request JWT in the authorization header and server sends you the data back. So it is just simple you just send a token. token is not stored anywhere on the server. It just validated it. That's why it is called a stateless authentication because we are not storing the state of the token anywhere on the server. So this is how simple login flow looks like. What we have is login API where we are passing email password. It will reach to the server. Server will check the uh the user exist and it will return a JWT token. So how we are returning JWT token? Using JWT sign. So it's like a process and then you return the access token to the customer to the client who is accessing the API right so first phase is send the login request validate credential create a JWT token using JSON web token module JWT dots sign this is the payload which you are encoding inside a token you also need to pass a secret key to create a token and the expiry so these are the three argument even if zero firebase create the JWT token they also have the same thing the the body the secret key which using which they are creating token and the expiry now the request validation is you start accessing the private APIs when you have token so you will send authorization header your middleware will extract the authorization header it will verify using gwtverify the same server has the secret key using same secret key I will try to verify the token if token is verified the claims are verified I will be allowing you to access the data so this is the pure stateless I don't need to worry about storing the session at the server side if token is coming token is valid I will enrich this request session with the user information and I should be able to fetch the information for the user so now the next thing we'll talk about is this diagram so let's see here this is a client and this is a server We will look up into the database and we will return the token. Right? So this is a simple login. We will store the token and we'll send it to to the server side. I mean here JW token we are saying stateless that means we don't need to store it anywhere. But when you talk about uh refresh token access token and you want to provide a feature of refresh token then maybe you need to store some metadata based on that you can regenerate the access token every time. Now the client will send a request with the token. We will verify the token. There is no database call right because we are validating only token and if token is valid we get the user ID. We will just start accessing the data based on that user ID. So this is fast. This is how this is the end to end JWT token flow. Now the important point is not every time you are creating token by yourself because if you are using external provider like uh AWS, Cognto, Ozero, Firebase or any other provider which is taking care of your authentication like user management is uh provided by octa or zero key clock or any other platform then you don't need to worry about creating token but you are also writing your own custom APIs.

[00:07:43]those APIs users would be able to access only when you are providing a valid token. So how those external API how do your APIs will be able to validate a zero token which you haven't created the Firebase token which you have no control but there is a way to validate it. If I'm creating token, I'm building the user authentication in my micros service o microser where I do I'm allowing user to login create a token send a token to the client client is coming back with the token then obviously I can do the jwtsign to create a token jwt.verify verify to verify the token or I will use just a NestJS, NestJS passport, uh JWT, JSON web token all these libraries combined together they will be able to do it but when we are doing external provider like O0 Firebase AWS Cognto and key lock how can we validate the token coming from these external parties let's say you integrate O0 tomorrow or zero will allow you to login it will give the token to your front end application and then front end will send the token to your Nests API or express API TypeScript API. How that API can validate the token, right? This would be a way. So that is done by JWS endpoint. This is the endpoint where all zero key clock all these external parties provide the public keys. This is similar to like if your ozero tenant.com it's like common. You just need to replace your tenant name here like example.org.com.

[00:09:22]Similarly for the Firebase, Cognto and for key clock right now this is the step one that okay you got a token. Now how to validate a token? This is the first primary key public key which this URL will help you. Now if this URL is there then it is very easy. JWKS validation is very easy. What what happens is these external parties exposes the public keys. Okay. when you hit this URL you will get the response something like this keys key id use and all. So validation scope what we will do we will try to extract the key id from this uh JW case URL and then for that key ID uh this is how you will request JWKS endpoint search the JW case response with the for the key that is matching with your ID you will get the token and then JWverify you'll pass the public key so here you we are not passing the secret we are just trying to verify if this token is valid And that verification for that verification you just need a public key right which you can get from their JWKS endpoint. If this is fine that means and you can check the issuer if both are validating expiry is greater than now. Okay you can still use this token and access the APIs. So how all these things combine together and happens with the nests when you are using when you are building o service without uh the third party like ozero then it's easy what I do is here instead of this I just provide a secret or key provider right you might have seen this code here if uh you are actually validating the or zero token from the external provider then you will use this library JW case RSA here you can See the role of it JWKS RSA JWT secret here we are providing a JWKS URI that is very important point how we how we verify it let me zoom it a little bit so you can see this is very important here we are providing a JW case URI from ojro firebase cognto your issuer tenant name audience if you are using it algorithm rest all the logic will be same how you have written JWT's strategy for your local authentication now let me show you the simple code to explain you how this really works so this is the one way or you can write a custom middleware and do all those things together but JWT strategy the passport JWT provide a simple wrapper around it which can help us because this particular line will be able to extract authorization header from the request and it will give us there you don't need to write request dot headers do authorization because this this inbuilt module is doing it so this is a simple uh NJS code and what I'm doing is o controller you can see I have o login validate user it will just generate a token and it will return the token in the cookies now I want to show you uh how we can hit a protected API.

[00:12:42]So important code here is this JWT og guard what it is doing if you are using provider config let's say you are using oz0 firebase etc then how we validate the token is different we get the token from the bearer then we will use the secret or a key provider because here it can be firebase or zero cognto or anything here we are providing a jwks uri so this is how it will work otherwise we'll go with our fallback very basic okay we just provide our own secret. We get the token from the authorization header. Very simple. This can be your Oguard JWT strategy which will be used by JWT Oguard and rest all will be the same. So this JWT Oguard is using JWT strategy internally and it is applying for all the API routes which are protected which are not public. This all these things cards are getting applied and this can there can be handled errors like unauthorized exception token invalid exceptions if you are passing invalid token. So this is simple demo which explains how you can use token based authentication internally like you are just building your own or externally when you are integrating with ojiro firebase and cognto. How can you protect your nests APIs when the token is coming from the third party?

[00:14:02]I used to write a custom middleware but uh this is the nice and the clean way of validating the token. I really like it.

[00:14:10]This is the NJS passport already support this thing. Otherwise you can write a middleware go to that JWKS URI manually get the keys and do all those things manually in the middleware or you can just use this utility and get everything done.

[00:14:26]So that's all I wanted to cover about token authentications and how we can deal with the external providers in the NestJS.