0

Why the JWT important more then hashed password?

So I've read some of articles about the JWT mechanism and I'm pretty sure I can say that I've got the concept.

We do have secret key in the server side. We get base64encrypted (heade.payload) - and with the whole thing we verify if the token we got by the client is valid.

Well, so far so good. But, since the client can read the payload (by decode64..), he can change the payload and also get verified with some else payloads.

Let's say I have a verified token, this token also stored in my db in "x" user. Now I want to change the email of my user (user "x"). Can I (as the system developer) trust only about the matched tokens (db token in user "x" and the token the client sends)? Or do we need more extra check with email+password for example? The thing is the token value no longer valid after X hours?

I saw examples which the client, after he authenticate via JWT - needs also to provide email & password to truly check if the credentials are correct... So what we've done here more then just add some extra weak barrier before the real authentication by the db and client credentials?

And if the token is for encrypt the user credentials - since anyone's who got the signed token can read the payload, why not just we save directly the credentials (email+password) with cookie or something like this?

What do I missing here?

################

EDIT -

To be more clarify: So let's say there is such a scenario: A user enters his private personal area to view the messages he has received. It sends an API request to "/api/my-profile" with the TOKEN which is "header.payload.secret". The system does verify - ok by now, the user did provide a proper TOKEN. Now my question, is -

  1. Can the system trust the user here (because the TOKEN was authenticated), and retrieve the private messages for him according to the PAYLOAD that the user requests (say {user_id: 10})?

or

  1. The system, even though it has verified that the TOKEN is valid, needs further verification that the user is indeed who he says he is (user_id = 10)? And to verify this I think she must get the user's encrypted password with id / email (something unique)?

From my understanding Case 2 is correct because surely in Case 1 there is a serious security issue (since any user, even if verified, can request details of another user).

--

Here is 2 verified JWT with only changed the payload: 1 - https://jwt.io/#debugger-io?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoiMTAiLCJwYXNzd29yZCI6ImFiYyJ9.BoiVLHPTCtpcp7P9BIan9ZptJHvxUlOmoAoAUqHvjJE

2 - https://jwt.io/#debugger-io?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoiMTUiLCJwYXNzd29yZCI6Im5vdC1tYXR0ZXIifQ.i6TkRDnyqcDsgwbFnG9QfSI1Wayj5YmwEOqydxU2MMo

Hope my question is more understood here

Matan Maimon
  • 47
  • 8
  • Does this answer your question? [If you can decode JWT, how are they secure?](https://stackoverflow.com/questions/27301557/if-you-can-decode-jwt-how-are-they-secure) – jps Dec 31 '21 at 08:16
  • *base64encrypted* - Base64 is an encoding algorithm, it's not meant to encrypt anything. - *since the client can read the payload, he can change the payload and also get verified with some else payloads* - No, because the modified token will be invalid. See also linked Q/A. – jps Dec 31 '21 at 08:19
  • Here is 2 verified JWT with only changed the payload: 1 - https://jwt.io/#debugger-io?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoiMTAiLCJwYXNzd29yZCI6ImFiYyJ9.BoiVLHPTCtpcp7P9BIan9ZptJHvxUlOmoAoAUqHvjJE 2 - https://jwt.io/#debugger-io?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoiMTUiLCJwYXNzd29yZCI6Im5vdC1tYXR0ZXIifQ.i6TkRDnyqcDsgwbFnG9QfSI1Wayj5YmwEOqydxU2MMo – Matan Maimon Dec 31 '21 at 12:43
  • 1
    When you have a token in the jwt.io debugger, you can change whatever you like and get a verified signature, even if you did not provide a secret or key. Please see [here](https://stackoverflow.com/questions/69862105/jwt-io-says-signature-verified-even-when-key-is-not-provided) how you can really verify a signature on jwt.io. But if you have a token that was signed with an unknown key, it's impossible to change anything in the token and cheat the original issuer of that token. Without knowing the key, you can't create a valid signature (i.e. valid for the private key of the issuer) – jps Dec 31 '21 at 13:11

1 Answers1

1

The token is not for encrypting your credentials. Is all about giving access to API's and authenticating the user.

The benefit with using JWT tokens istead of username/password is that it is easier to refesh the JWT token than having all your clients to update username/password.

No-one receiving or seeing the JWT tokens will not be able to modify it, because they do not have the private key that the tokens were signed with. They can only validate it, using the public key.

Also with openid-connect, you delegate the authentication to some trusted service that do the authentication for you and you use JWT-token to transfer the identity of the user (IDToken) and access tokens to get access to APIs.

Tore Nestenius
  • 16,431
  • 5
  • 30
  • 40
  • Please refer to my edit – Matan Maimon Jan 01 '22 at 16:15
  • Modern systems tends not to use HS256, instead they use RS256 that is more secure. After you receive the token, you need to retrieve the details for that user. The problem with HS256 is if the hacker gets hold of the shared secret, then the hacker can fake those tokens. The token is only about the authentication, then you need to check if the claims in the tokens like "IsManager" or "IsEmployee" is allowed to do the requested action. – Tore Nestenius Jan 01 '22 at 16:31