I am going to apply JWT into my REST API developed using Java-Jersey. I am using this library for JWT - https://github.com/auth0/java-jwt
I have few questions about the JWT - Secret
Secret
has to be unique?The minimum secret length for HMAC: A key of the same size as the hash output (for instance, 256 bits for “HS256”) or larger MUST be used with this algorithm. The minimum key length for RSA: A key of size 2048 bits or larger MUST be used with these algorithms.
To reiterate, whatever you do, don't store a JWT in local storage (or session storage). If any of the third-party scripts you include in your page is compromised, it can access all your users' tokens. To keep them secure, you should always store JWTs inside an httpOnly cookie.
Anatomy of a JWT Figure 1 shows that a JWT consists of three parts: a header, payload, and signature. The header typically consists of two parts: the type of the token, which is JWT, and the algorithm that is used, such as HMAC SHA256 or RSA SHA256. It is Base64Url encoded to form the first part of the JWT.
By design, anyone can decode a JWT and read the contents of the header and payload sections. But we need access to the secret key used to create the signature to verify a token's integrity.
- Does this
Secret
has to be unique?
It should be unique to your application — it needs to be a secret, after all — but it won't be unique for each token. Rather, you should have a relatively small number of secret keys at any given time (e.g., usually having just one key, but having brief periods where you have two keys as you rotate from one to the next).
- Shall I use the hashed version of user's password for secret?
No, for two reasons:
GoPackers123
. Using the password in your secret then means that someone can easily test a given potential password to see if it results in the right signature; and, more to the point, they can easily test huge numbers of potential passwords to see if any of them gives the right signature. This is an offline attack, so you would never even know it happened.JWT and the java-jwt library support both symmetric and asymmetric algorithms for the signature:
If you go for symmetric algorithms such as HS256, you will have only a single key to be used to sign and verify the signature.
If you consider asymmetric algorithms such as RS256, you will have a private and a public key. Keep the private key safe on the server and use it to sign the token. Use the public key to verify the signature (it also can be shared with whoever needs to verify the signature).
Never ever share the key used to sign the token!
And nothing stops you from having a set of different keys for signing your tokens. In this situation, the kid
header parameter can be used to indicate which key was used to sign the token. This claim is supposed to carry a key identifier and not the key itself.
Refer to this answer for more details on the kid
claim.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With