0

I am facing an issue while validating Okta token using JWTTokenValidator.

For ex token is : eDue41r18EPlCG8JwTAxYAv15jfInh$$$$$$9hf6H6XBZYSradVOSk9A7wvwB3oJT-mlXT&&&&&&orwa3SIRffZCKunOUKiA*dyvlx0BQutl3YYdfuBzk4OlhqNlump@@@@@JARQg

Case 1 : if i change here last character greater than g then Jwt validation got success(i.e unexpectable result).

Case 2: if i change last character less than g then Jwt validation got failed (i.e correct validation)

Okta jwt verifier version: '0.5.0'

I found two answers:

a. https://community.auth0.com/t/jwt-token-validation-issue/37911

b. JWT token decoding even when the last character of the signature is changed

Questions raised for the above solution (b) this solution suggests that it is algorithm specific -- If this is algorithm specific then how can we finalise on the Algorithm to be used and will arrival of new algorithm in future impact our algorithm ? -- Why this is not generic ? Expectation: Validation should fail for both case 1 and case 2. i.e if I replace any character in the token it should fail the validation

jps
  • 20,041
  • 15
  • 75
  • 79
Abhishek
  • 1
  • 1
  • Does this answer your question? [JWT token decoding even when the last character of the signature is changed](https://stackoverflow.com/questions/58492009/jwt-token-decoding-even-when-the-last-character-of-the-signature-is-changed) – jps May 25 '21 at 09:16
  • @jps Based on the answer given by you in about mentioned linked, are we saying validation/verification of Okta token is completely dependent on `Base64` encoding ? If yes, then which one is best out of `HS384`, `HS512`, `HS25` or something else which may introduce in near future & why ? How can we say that the application using Okta token (not bothering about, say last 2 bits which are from padding) is fully secured ? – OO7 May 25 '21 at 17:48
  • @OO7 *validation/verification of Okta token is completely dependent on Base64 encoding* - The signature of a JWT just happens to be Base64Url encoded, beside that I don't see how the verification *depends* on the encoding. The verification depends on matching signatures (i.e. a matching x byte long hash values). Wether these values are Base64Url or Hex or whatever encoded in the token should IMHO not be relevant. *which one is best* - for questions about information security the sister site https://security.stackexchange.com/ might be better suited than Stack Overflow. – jps May 25 '21 at 21:05
  • Thank you @jps for reverting on my queries. As you suggested, may be OP can ask this question in [security.stackexchange.com](https://security.stackexchange.com/) to understand more about security. – OO7 May 26 '21 at 09:56
  • *(b) this solution suggest that it is algorithm specific* please read again, it's basically depending on the length of the signature. If the length in bits (always a multiple of 8) can be divided by 6 without remainder, there won't be any insignificant bits on the end. Simple math. Why is this such a big concern? When the base64 encoded signature is decoded, you get a x byte long binary value, that's all that should matter. – jps May 27 '21 at 15:25
  • @jps QA team has raised this issue while changing last character in Okta Token they are expecting to get 'invalid token error message'. But right now we change in last character request is getting successfully. What is your suggestion about this? – Abhishek Jun 01 '21 at 20:02
  • I edited my answer about this topic on last weekend, so please read again. I hope it's a bit clearer now. Base64 encoding has been used for many years, not only but often to encode encrypted data of all kind. JWT is also around for some years now and the usage of bas64url encoding is part of the standard. I'm not a security expert, but aside from this frequently asked question I haven't heard about any serious concerns. I hope my answer or any other material about base64 encoding and signatures will help you to understand and then you can help the QA team to understand that there's no problem. – jps Jun 01 '21 at 21:49

0 Answers0