How to exchange keys in JWT between server and client and between shared servers?

Question

I'm not sure I have a full understanding of JWT when it comes to the signature. The signature, as I get it, validates to the server that the header/payload that was transfer from the client is legit.

So if I get it right it goes (almost) like this:

Say I'm Allison and I just logged in a server and was successfully authenticated. The server will generate a token (JWT) for which I'm going to use to communicate with the server.

It 'tells' me: use this KEY (example: SERVER_PW_0001) to hash your payload + header and that would be the signature and when I (the server) get your encoded token I will know it is from you because I'll use our secret shared key to hash the payload + header and I expect to get the same signature of yours.

So I'm asking:

1. After authentication, how does the server transfer the key to the client so only the client can read it?

2. when the server shares a secret key with a client is it for each unique client?

3. What is the payload for? if it is exposed out in the open (base64) what info is important to transfer from the client to the server and reverse in the payload/header?

4. say there's another server (server2) where the client wants to communicate with but without authentication (because it was authenticated already with server1) - how does server2 get the shared_key from server1 [1]: https://jwt.io/

Answer 1

It 'tells' me: use this KEY (example: SERVER_PW_0001) to hash your payload + header and that would be the signature and when I (the server) get your encoded token I will know it is from you because I'll use our secret shared key to hash the payload + header and I expect to get the same signature of yours.

A JWT is not used as a way to share a secret key, it's rather an 'entrance ticket' that has all your attributes, with a cryptographically secure signature. You send this ticket as a header along with your HTTPS request and the server will a) validate the ticket and b) extract your attributes therefrom (identity, permissions etc.).

So I think you're mixing stuff a little bit. TLS protects the connection (key exchange during the handshake, data encryption etc.), while JWT serves as a way to maintain client identity between individual HTTPS requests in a way that the server can trust.

As for your questions:

1. JWT tokens shall be transmitted over TLS, such that nobody else can read it (and impersonate the user). So for a secure JWT token usage, HTTPS is a prerequisite.
2. Not really relevant here. JWT tokens are basically a collection of attributes (say email, userid, permissions) signed by the server (either symmetrically, or asymetrically). No secret key exchange happening here.
3. The server can use JWT's payload to determine who the caller is and what they can do. It's the only way to tell individual users/requests apart from the server's perspective.
4. JWT tokens also support asymmetric signatures, such that server A can sign a JWT token, server B can choose to trust server A's public keys and therefore validate JWT tokens issued by server A.

To sum up, a client sends a HTTPS request with a header saying something like Authentication: Bearer myJwtToken The server takes this header, unwraps the JWT token, determines who the caller is and whether the request shall pass through, and only then acts on the actual request content.