Thanks for this great post. I actually just signed up to say that I actually wasted a considerable amount of time trying to create my own SIGv4 just to avoid replay attacks especially if the server is behind some L-7 load balancer such as Cloudflare more than any other reason. It was implemented like this: the server creates a ecdsa/ed22519 key pair, hands over the private key to the user and keeps only the public key, then for every request to the actual APIs, the user uses the private key to create a JWT that contains some attributes such as the userID, sessionID, the request path, etc...). While this method obviously looked much more secure than just a long-term static JWT or an access token, the real problem I found was in the clock skew, if the client doesn't have a well synchronized clock, then the JWT is deemed invalid by the server since such this JWT should be very short-lived by design otherwise what's the point of having them in the first place. If your clients are browsers or running on PCs, as opposed to servers, containers, etc... this will be a huge problem for you. In fact, AWS clients implement their own clock skewing correction <a href="https://aws.amazon.com/blogs/developer/clock-skew-correction/" rel="nofollow">https://aws.amazon.com/blogs/developer/clock-skew-correction...</a><p>I ended up implementing an additional auth API endpoint where you use your long-lived secret to periodically request a short-lived JWT that is only valid for a few hours, this short-lived secret is what is used for the actual APIs to authenticate the users.