1

On this website, it says:

Do note that for signed tokens this information, though protected against tampering, is readable by anyone. Do not put secret information in the payload or header elements of a JWT unless it is encrypted.

This part is clear to me, even by using the built-in https://jwt.io/ debugger I can see that the header and payload are only base64-encoded.

However, I do not understand how encrypting here (JWE is the term?) can improve security?

In the examples I saw the user passes their credentials like this and then uses the token they received (I understand the example is flawed as it does not use HTTPS - I'm asking specifically about HTTPS requests here).

So my question is if sending user credentials via HTTPS POST's request body is OK and best practice why wouldn't the same be true for the JWT's header or payload?

mariusz96
  • 66
  • 4
  • 1
    Sending unhashed user passwords over HTTPS isn't best practice. It's common, but it's bad. Passwords should be stretched before sending to the server. But that's not really the point here. You *are* encrypting the JWT. That's what HTTPS does. You're probably thinking that "send to a web server" is the only way JWTs are used so HTTPS is assumed. That's not close to true. They also can be stored on disk, or sent over a wide variety of protocols, including unencrypted protocols (such as your example of HTTP without TLS). – Rob Napier Oct 04 '22 at 12:08
  • 1
    @RobNapier - oh yeah, like, for example, when I want to store the token in the database. And indeed, I was only thinking about "send to a web server" scenario but there's surely other scenarios where tokens can be used - makes total sense, thank you. – mariusz96 Oct 05 '22 at 05:24

1 Answers1

0

Preliminary notes :

Each time something must be kept secret, you need to ask yourself who can share this secret to understand why it should be kept secret and therefore how to keep it secret.

Here, we have two objects that need to be kept secret, the token and its payload:

  • The token must be shared by the client and the service: it lets the client prove to the server that the client has an authorization to do a request, since the information is only known by those two parties;
  • The payload of the token does not need to be shared with the client, the information in the payload (identity about the client and claims about its rights to do something) is only here for the server to read it and take decisions from it.

therefore, sending the token inside an HTTPS flow lets the token only be known by the client and the server, not anybody else.

And encrypting the content of the token lets the information in this token only being known by the server.

This way, information is only disclosed to parties that need to know about it. This is a basic rule of information security.

However, I do not understand how encrypting here (JWE is the term?) can improve security?

As noted previously, this improves security because the payload has not to be disclosed to the client.

my question is if sending user credentials via HTTPS POST's request body is OK and best practice why wouldn't the same be true for the JWT's header or payload?

As noted previously, this is because when dealing with information security, you should never share information that is not needed to be shared. Since the credentials send by the client need to be disclosed to the server, because this is the only practice with such a credentials type that can let the server check that the client owns the good credentials, and since it is sent over a secured channel, no one else can get those secrets, therefore this practice is a best practice. But disclosing the content of the token (payload and signature) to the client is not needed to perform the authentication. So it would not be a good practice to do that.

Alexandre Fenyo
  • 4,526
  • 1
  • 17
  • 24