JWT Verify client-side?

Question

I have a nodejs api with an angular frontend. The API is successfully using JWT with passport to secure it\'s endpoints.

I am now conscious that after the tokens have e

Answer 1

TL;DR

1. You must verify the signature of JWS in the server always.
2. Client-side signature verification doesn't gives much, unless you have a specific case where it makes sense don't do it.
3. You don't need to verify the signature of a JWS token to check expiration in the client. (unless you were encrypting the claims, aka using JWE, in that case you need to do something similar because you need a key to decrypt the claims).
4. You don't need to verify the signature of a JWS to check expiration in the server neither, but you should because this gives you the certainty that nobody has altered the expiration (otherwise the verification will fail because if the claims change then the recalculated signature will differ)
5. To read non encrypted claims you just only need to decode them. You could use jwt-decode in the client.

I am now conscious that after the tokens have expired, my front end will still allow the user to request my api endpoints [...]

So to implement this logic I think I need to verify the JWT token client-side

If I understood you correctly you are talking about checking if a JWS has expired in the client side. In order to do this you don't need to verify the token signature (although the library you are using seems to be doing both things at the same time for you, but also lets you to disable expiration control with ignoreExpiration flag). (Unless you're encrypting the claims, aka using JWE) The RFC 7515 (JWS) says nothing about expiration. Message Signature or MAC Validation doesn't control expiration (and it shouldn't because signatures gives you authenticity and integrity). Even the RFC 7519 (JWT) doesn't control the expiration claim for resolve if a JWT is valid or not.

Also, all the claims are optional.

So, you could check if a JWT has expired or not without verifying the signature, hence you don't need neither a public key (for asymmetric encryption like RSA) or a secret key (for symmetric encryption like AES). In JWT and JWS tokens, the claims are just plaintext base64 encoded so you could just decode the payload without verifying if the signature is valid and read the expiration claim. If you are encrypting the payload (aka using JWE) then you will not be able to do this.

A note from jjwt library

JWTs can be cryptographically signed (making it a JWS) or encrypted (making it a JWE).

Here is a ligthweigth library from auth0 to decode the base64encoded claims of a JWT/JWS token. A guy is even asking about checking expiration.

I don't know why you think that you should be doing this control client-side, the only advantage is avoiding sending API request that the client knows that will fail. And they should fail because the server should be validating that the token hasn't expired, previous signature verification (with secret/private key) obviously.

The RFC 7519 says about this claim:

The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing.

In a web app like the one you say the use of tokens is to allow stateless servers to authenticate client requests. The goal of the OPTIONAL expiration claim is to allow the server have some control over the generated JWS (if we are using JWT for authentication signing them is a must so we should be talking about JWS).

Without expiration, the tokens will be valid forever or until the key used to signing them change (this will make the verification process to fail). By the way, invalidating sessions is one of the most notorious disadvantages of using stateless authentication.

Session invalidation becomes a real problem if we are including information in the JWS payload (aka claims) used for authorization, for example which roles the user have.

From Stop using JWT for sessions

but more seriously, it can also mean somebody has a token with a role of admin, even though you've just revoked their admin role. Because you can't invalidate tokens either, there's no way for you to remove their administrator access

The expiration control doesn't solve this problem and I think is more oriented to avoid session hijacking or CSRF attacks.

An attacker using CSRF will be able to make a request with an expired JWS to your API skipping the expiration control.

A different issue is verifying the signature in the client using the public or secret key.

Regarding your question

I am using seems to require a public key to use it's verify() function. I don't seem to have a public key, only a secret, which I just made up, so it wasn't generated with a pair.

The verify method you pointed out says explicitlly that it accepts a public or secret key.

jwt.verify(token, secretOrPublicKey, [options, callback])

secretOrPublicKey is a string or buffer containing either the secret for HMAC algorithms, or the PEM encoded public key for RSA and ECDSA

I assume you are using neither and you are using a string like 'shhhh'.

var token = jwt.sign({ data: '¿Donde esta Santiago?'}, 'shhhh');

Then you should do

var decoded = jwt.verify(token, 'shhhhh');

However, the question here is: Is client-side signature verification really needed?

I think is not, at least not for this kind of application where the client just uses the JWS to send subsequent request to the server saying: "Hey server, I'm Gabriel and I have a paper (token) here that assures that and that paper is signed by you." So if the client doesn't validate the JWS and a MITM had successfully gave to that client a JWS signed by himself (instead to the JWS signed by the server), then the subsequent request will simply fail. Like expiration control, signature verification only prevent the client to make request that will fail.

Now, client side verification requires sending the public or secret key. Sending public key doesn't represent a security concern but it's extra effort and processing with little benefits.

Sending secret keys (like 'shhhh') can represent a security issue because is the same key that is used to sign tokens.

Answer 2

Q1: Token verification on client is a bad idea. What you can do is to save a token together with a same expired date on client and then refresh/remove a token. But my thought that it is better to have some date checkig on server side cause exist simple rule: Don't trust the client cause it can always send malicious code.

Q2: JWT don't need any public key. It always must have private key storing on server side cause if someone known your secret key your token don't make any sense. You only can add some payload to do it more complex.

Answer 3

I think verifying JWT token at client-side is not a good idea.
IMO;

1. Whenever a user logs in, generate access and refresh token and return to user something like this;

   { "accessToken": <<accessToken>> "refreshToken": <<refreshToken>> "expiresAt": <<expiresAt>> }

   So client can understand when access token expire and can refresh it with refresh token.

2. Encrypt the data that you put in the access token because there is a chance to access the data without secret key. But of course someone needs to secret key to verify.

Answer 4

Answer 1: It is not considered to be a good approach to verify your auth token on the client side as it involves secret key while encoding/decoding it and keeping the secret key on the client side is not secure.

Creating Token

jwt.sign({ data: 'foobar' }, 'secret', { expiresIn: 60 * 60 });

Verifying Token

jwt.verify(token, 'secret', function(err, decoded) { console.log(decoded.foo) // bar });

Answer 2: JWT involves secretORPublic key while encoding and decoding token. It has to be declared or kept in the config file somewhere on the server side.

Explanation: Decoding means decoding from Base64, there's no secret key involved in that process. On the other hand, verifying a JWT would require a secret key because it would involve a cryptographic signature operation.

To sum up, decoding does not need the secret (remember decoding is just interpreting base64) and verifying/signing does require it