search

auth0 / java-jwt

Java implementation of JSON Web Token (JWT)
MIT License
5.89k stars 922 forks source link

can add a new verify method? #306

Closed kibear closed 5 years ago

kibear commented 5 years ago

Hi, I store some data like user id in token, before invoke verify, I need decode token and get the data, then use the data to find secret, but now only have one verify method with string token, can add a method like verify(DecodedJWT jwt)，I decode the string token to a jwt object, then verify the jwt object???

lbalmaceda commented 5 years ago

If your "data" is a key id and your "secret" a public key, you could use the KeyProvider class to delegate that fetch (using whatever method or library to obtain it). If this is not your scenario, why would you trust an unverified token's data? You shouldn't.

Possible dupe of https://github.com/auth0/java-jwt/issues/279.

kibear commented 5 years ago

If your "data" is a key id and your "secret" a public key, you could use the KeyProvider class to delegate that fetch (using whatever method or library to obtain it). If this is not your scenario, why would you trust an unverified token's data? You shouldn't.

Possible dupe of #279.

every token has a particular secret, I need decode the token get the 'data', then use the 'data' find secret. I donnot trust the token, I just get some claim from token, once I get the secret, I will make a Verifier object use the particular secret, then verify the token. Now, I need decode token string first, and then verify method decode it again, it look like a waste.

oh, I use Algorithm HMAC256, it cannot use keyprovider.

lbalmaceda commented 5 years ago

I see. What if an attacker takes your token's payload, replaces the "data" you're using in your "find my secret" step with something they already know it's mapped to a given "secret" value. Then they re-sign the token using that same secret. When is your time to verify the signature, they have already replaced the signature with the one they created for the secret both you and they now. Thus, after your verification passes you will be using your token's contents thinking that no one has tampered with them mistakenly. I suggest you host a pair of public keys (the JWKS) and move to use RSA256 instead as it protects you from this scenario.

I'll consider the issue linked above but keep the conversation in there.

kibear commented 5 years ago

I see. What if an attacker takes your token's payload, replaces the "data" you're using in your "find my secret" step with something they already know it's mapped to a given "secret" value. Then they re-sign the token using that same secret. When is your time to verify the signature, they have already replaced the signature with the one they created for the secret both you and they now. Thus, after your verification passes you will be using your token's contents thinking that no one has tampered with them mistakenly. I suggest you host a pair of public keys (the JWKS) and move to use RSA256 instead as it protects you from this scenario.

I'll consider the issue linked above but keep the conversation in there.

thanks, but I'm a little confused, I parse the token, use claim data find a relevant 'secret', use the 'secret' generate Algorithm.HMAC256('secret') instance, then use the Algorithm instance generate JWTVerifier instance, and then use JWTVerifier verify token. The attacker impossible to get the 'secret', they just known verify success or fail, so they cannot re-sign token with the 'secret'.

lbalmaceda commented 5 years ago

The short answer is no, this is not supported today and possible not on this version. I encourage you again to use RS256 instead and asymetric keys to sign/verify as this scenario is supported OOTB with the KeyProvider. Feel free to take this discussion to issue https://github.com/auth0/java-jwt/issues/279 since its related. I'll close this one.