I just read this article that is a few years old but describes a clever way of securing your REST APIs. Essentially:

  • Each client has a unique public/private key pair
  • Only the client and the server know the private key; it is never sent over the wire
  • With each request, the client takes several inputs (the entire request itself, the current timestamp, and the private key) and runs them through an HMAC function to produce a hash of the request
  • The client then sends the normal request (which contains the public key) and the hash to the server
  • The server looks up the client's private key (based on the provided public key) and does some timestamp check (that admittedly I don't understand) that verifies the request is not a victim of a replay attack
  • If all is well, then the server uses the private key and the same HMAC function to generate its own hash of the request
  • The server then compares both hashes (the one sent by the client as well as the one it generated); if they match, the request is authenticated and allowed to proceed

I then stumbled across JWT, which sounds very similar. However the first article does not mention JWT at all, and so I am wondering if JWT is different than the above auth solution, and if so, how.

  • 1
    Lol... I just wanted to ask the same exact question and came across yours. One of the first things I found about stateless authentication was from the AWS: docs.aws.amazon.com/AmazonSimpleDB/latest/DeveloperGuide/… , and implemented something like this massimilianosciacco.com/… . Then I found JWS/JWT and it is somehow similar. But as far as I understand JWT is a standard and the other solutions described above are some custom implementations (not standardized). Someone correct me if I am wrong.
    – nyxz
    Sep 16, 2015 at 15:55
  • 2
    Good to know I'm not the only one worrying about these kinds of details! JWT certainly feels similar, and the bonus is that it's standardized. I'm just wondering how it fairs (security-wise) with this custom HMAC solution.
    – smeeb
    Sep 16, 2015 at 16:51

1 Answer 1


Let's get this started with a very basic answer.

JWT (as used in the context of OAuth and OpenID) does not require shared secrets between client and API. There are 3 components and pairs of 2 share a secret each: client <-> identification server, identification server <-> API.

This moves most complexity from the API to the identification server, the API just has to check that the token was issued by the identification server and was not tempered with. To verify that the API checks that the JWT-signature is valid with the known single shared secret between identification server and API. That's it!

How the identification server validates the user identity can vary widely (in many cases it's the old username+password pair over a TLS-connection), but is of no effect on your API.

Privacy and security of the message and the token itself when using JWT are handled by TLS, JWT is ignorant of such issues.

  • I found this answer to be confusing. It handwaves details like, "JWT (as used in the context of OAuth and OpenID)" Might be worth explaining why that is instead of assuming the readers implicitly understand that. Oct 19, 2021 at 17:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.