How is JWT token authenticated?

Question

This has me confused:

• So when a user logins, they are granted a JWT token with a signature. This signature happens with header+Payload+secret

• Now the use has a token and they can access protected resources.

• How does JWT know that a token is valid? Since nothing is stored on the server in this flow, how would a comparison be made agains the signature? If I go to a JWT debugger, I can just create a token which would also be valid. So how does that part work?

The last bit has me very confused. Everywhere I see "checks signature" but no one is explaining it in detail.

Answer 1

JWT (JSON Web Token) is a self-contained access token, which means it contains all the information needed for an application to consume it (i.e., JWT Claims) & the server to validate it (i.e., JWT Headers & JWT Signature). All of it in one token.

Server validates JWT by asking these two questions.

Has the JWT been expired?
Has the JWT Payload been tampered?

First one: Server looks at JWT Payload for registered claims like "exp" (expiration time), "iat" (issued at) claims to determine if the JWT is expired (or) not.
For a list of full registered claims, refer RFC 7519 here.

Second one: Server looks at JWT Header for a registered claim "alg" (algorithm) to know which type of hashing was used during the JWT generation. It uses that same algorithm (but, with the server's own secret) to validate if the JWT Payload has been tampered during the way.

Hope that clarifies.

cheers,
ram

Answer 2

There are quite a few and fairly generalised questions here, so I've broken this down a bit...

1. How does JWT know that a token is valid and not an imposter token?

When you submit a request to your server, a JWT is attached to the headers of that request. This JWT has been previously provided by the server (upon authentication) and is usually stored in localstorage or cookies, in order to persist sessions.

One can then use the "jsonwebstoken" package (server side) to determine the validity of a token to a particular resource. The JWT package will decrypt the token and compare its signatures. This is done by comparing the secret key, which should never be exposed client side This is one variable that could render the token invalid or valid. Another might be if the tokens expiration has timed out. For instance, if an attacker has stolen someone else's token, they might try to send that token to your server and impersonate someone else. Thus, it's good to have a short expiration 15m - 1h

2. How is a token valid to a specific route?

Well, this is where the variables are limitless. JWT permits you to store information inside the token. For instance, if you have two different user groups you would have a value stored in the token - when it is originally signed - stating whether a user belongs to a specific user group. e.g. userIsABuyer: false, or userIsASeller: true. A good practise would be to write some middleware to intercept every request that comes in and check if a token is valid. If it is valid, you could attach a header, for example, "authenticated: true" and to further protect other internal resources, you could attached any number of headers. For example, "userIsABuyer: false"

https://www.youtube.com/watch?v=25GS0MLT8JU - this is a pretty good video that goes through JWT's in some depth.

https://blog.hasura.io/best-practices-of-using-jwt-with-graphql/ - an excellent resource that also covers deal with the problem of persisting sessions in front end apps, when storing tokens in memory

Answer 3

JWT create clients token based on a secret key that the server has. JWT is designed on a way those clients token can not be generated without the key the server has, so every key is secure always the secret key is secure. Also the server use the secret key to verify the client token is valid and only that secret key can validate it.