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:
- 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.
- 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.
- 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.
- 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.