JWT: In a server-to-server request, should I sign the entire request body?

Question

Let's set the scene with two servers:

1. an "auth" server which provides users with authorization tokens containing claims relevant to their account
2. a "paywall" server, which after receiving payment from a user, will send a request to the auth server to add the "premium" claim to the user's account (and also this server can serve out restricted content to users who have the claim)

Both servers have access to a shared secret key, so the paywall server can verify the user's claim to view restricted content.

I want to verify that any claim-altering-requests which the auth server receives are actually coming from my trusted paywall server.

My thinking is that the paywall server should simply sign every claim-altering-request in its entirety within a JSON Web Token, such that the auth server can verify the identity of the sender, and also verify that none of the requests have been tampered with.

In this case, it seems like the entire request body would simply be one big JSON Web Token (instead of a mere Authorization header) because I can't trust any data which isn't signed within the JWT.

Does this reasoning make sense, or is this overkill? is my solution redundant? perhaps HTTPS can already effectively solve this problem? I think of HTTPS as a means to secure the communications between two points, however, this might not guarantee the identity of either end?

Answer 1

after some research and discussion about this question, i think found the answer to move on

i've moved from symmetric (HS256) json-web-tokens to asymmetric (RS256)

• now each server has its own private key, and they share each other's public keys
• this means neither server can impersonate the other
• this is a superior architecture for microservices, because now a third-party (untrusted) microservice can participate in the network

next, should we place the entire request body into a JWT?

• sure, this will work and be secure
• however, it's technically overkill — we could just use the underlying crypto to sign the whole request body, and then attach the signature as a header — which would be nicer, because then the request body isn't obfuscated as base64, which would be convenient
• for my use-case i will explore the idea of attaching a signature as a header, however if it feels shaky and like i'm rolling-my-own, i might just stick to only using JWT and wrapping the entire request that way as a token, which lessens the number of ways that i'm using crypto altogether in the system, so it's a trade-off