1

This is my first time using JWT. I'm using the jwcrypto library as directed, and the key I'm using is an RSA key I generated with OpenSSL.

My initial inclination was to store the JWT in the database with the user's row, and then validate the token's claims against the database on every request.

But then it occurred to me that the token payload is signed with my server's private key.

Assuming my private key is never compromised, is it safe to assume that all data contained in the JWT, presented as a Bearer token by the user, is tamper-proof? I understand that it is potentially readable by third parties, since I'm not encrypting.

What I want to know is, is there anything I need to do to validate the user's JWT besides decrypt it and let the library tell me if there's anything wrong?

3
  • do you mean secret key or private key?
    – Jasen
    Commented Mar 8, 2020 at 6:55
  • Please correct your question or your title. One says you're not encrypting, but the other talks about decryption. If you just mean signing and verifying, use those terms instead.
    – CBHacking
    Commented Mar 9, 2020 at 5:11
  • 1
    @OnNIX May I suggest a new title? "Is it safe to assume that a JWT is valid if the library says so?"
    – Irfan434
    Commented Mar 9, 2020 at 11:38

1 Answer 1

3

The way to verify a JWT is to check it's algorithm, signature, expiry and issuer. Other claims can be checked too.

Signature

For RS256, the auth server will calculate a SHA256 hash of the header and payload, and sign it with it's private key. To verify the signature, the relying party again calculates the hash of the header and payload, and checks that it matches the signature decrypted with the public key.

Since the header and payload aren't encrypted, they can be tampered with, but then it won't match the signature.

Algorithm

Two serious vulnerabilities are possible when the server does not check the "alg" field [1]. This is because some JWT libraries verify the signature automatically using the algorithm provided in the header.

Firstly, if a hacker sends a JWT with the alg equal to none, the signature won't be checked.

Secondly, some faulty library implementations store the symmetric secret key and asymmetric public key in the same variable. If you've stored an RSA public key expecting an asymmetric algorithm, and a hacker sends a JWT with a symmetric signing algorithm, your server will check if the JWT was signed with the public key. Since the hacker has access to the public key, they can easily create valid JWT signatures.

Payload Claims

JWT libraries will check the current time is between the issued time iat and expiry time exp. Instead of checking the exp, some people prefer to check the current time is less than the issued time plus the maximum acceptable JWT lifetime.

The issuer iss should match the expected issuer.

Sources

[1]: https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries
[2]: https://auth0.com/docs/tokens/guides/validate-jwts

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .