Why should JWTs need to be verified by the client?

Question

So my understanding is that a JWT is signed by the server with a private key and its legitimacy verified by comparing the public key decrypted signature against the header + payload by both/either the server and client:

The tokens are signed by one party's private key (usually the server's), so that both parties (the other already being, by some suitable and trustworthy means, in possession of the corresponding public key) are able to verify that the token is legitimate.¹

I'm just wondering what need is there for the client to verify the authenticity of the JWT? I understand the same mechanism is used for SSL, in which case client-side verification makes sense to me as the certificate contains the public key used by the client to encrypt the initial handshake. But I struggle to understand what benefit public verifiability serves in the case of JWTs. If the JWT were illegitimate, it'd fail on the server anyway, and the client isn't doing anything special aside from tacking it onto the request.

Couldn't just hashing with some private salt on the server satisfy the purpose it serves? The server verifies by hashing the payload with the same salt and comparing against the signature. In this case, only the server can verify, but so what?

Answer 1

So my understanding is that a JWT is signed by the server with a private key and its legitimacy verified by comparing the public key decrypted signature against the header + payload by both/either the server and client:

Thiis is incomplete. A JWT can be signed with the private key of a key pair(e.g RSA), or using a symmetric key(e.g HMAC). In this case the same secret key is used to sign and to verify the token

I'm just wondering what need is there for the client to verify the authenticity of the JWT?

When the token is signed with an asymmetric key pair is expected that the client verifies the token. Using a symmetric key, it is only known by the issuer party, so the client can not verify it

See my answer here: When to use RS256 for JWT?

I understand the same mechanism is used for SSL, in which case client-side verification makes sense to me as the certificate contains the public key used by the client to encrypt the initial handshake

Some data used in the handshake is digitally signed (not encrypted) by the server with its private key, and verified by the client

If the JWT were illegitimate, it'd fail on the server anyway, and the client isn't doing anything special aside from tacking it onto the request.

No, if the verification server is not the same that the issuing server (see the above link one more time).

Suppose the token has been issued by a third party ( e.g. goggle or facebook) as a result of an oauth2 authentication process. It can contains the details of the connected user, and it has been provided to your server using a redirect, so you can not trust the calling party. You must verify that the token has been issued by the expected party.