There is much info on the internet about JsonWebTokens, but not a lot about using it to sign the content of the HTTP message.
So it can sign its own claims, but it is not clear to me if there is a standard way (and available implementations) to let it carry a signature of the body of the message (at the very least, whatever is below the HTTP headers).
That's paramount, because if another client stole the token itself, it could be used to craft non legitimate requests until it expires.
That's the only resource that I found so far about the topic: API Message Integrity With JSON Web Token (JWT). The title is promising but the article doesn't really tell how to go about that, it is just showing the interest in doing so.
By the way, as a plus, if it is possible to sign the content of the body, a fail-fast implementation of the signature's validation would be great, for instance a piece-wise one (say, to discard the message if it immediately recognizes the first 10kB have been tampered, instead of having to ingest the whole 10MB message).
More details
I am aware that JWT is a token, so the common usage is having an authorization party deliver the token to the client, which will then forward it transparently in its requests to the server. So the auth party has no idea what actual requests the client will do next, and won't be able to sign the content of such requests (which would also be impractical, a different "token" should be issued for each request). It merely gives the token to the client which would be attached by the client, unaltered, to each request.
But I suppose that in some cases in the real world, the JWT is also produced by the client itself (not by a third party) which means that the client knows the shared secret, and legitimately signs the requests for itself.
In that case the client may, in principle, sign the content of the http body, not only the contents of the JWT token.
All in all, I suspect that the JWT format doesn't cater for such signature. The client and server should define their own protocol/format to do that.
Disclaimer: I'm by no means a security expert.
A JWT's job is not to sign the content of a request body, it's to provide verifiable information to a receiving service about the origin of the JWT and the claims it contains. So, when your service receives a JWT, you can verify some or all of the important aspects of it:
And so forth.
As to how to make sure the content of a request is what it purports to be, that is the job of TLS - transport layer security. The TLS handshake process is where the sending and receiving servers essentially get to know each other, validate that each are trustworthy, and generate their own asymmetric keyset (per session!) to encrypt traffic between them.
So, the point of TLS is to ensure that data sent by one trusted source arrives intact (and encrypted) at another trusted source where it can be decrypted. While not exactly the mechanism you asked about, I believe it meets the goal.