跳轉到

Request Authentication

In this pattern, we’ll explore how and why to use public-private key exchange and digital signatures to authenticate all incoming API requests.

This ensures that all inbound requests have guaranteed integrity and origin authenticity and that they cannot be later repudiated by the sender.

While alternatives (e.g., shared secrets and HMAC) are acceptable in the majority of cases, these fail when it comes to introducing third parties where nonrepudiation is required.

Exercises

  1. What is the difference between proving the origin of a request and preventing future repudiation? Why can’t the former dictate the latter?
When someone else (not user 1234 and not the API server) needs to verify that user 1234 was the true origin of the request? How can this third party tell the difference between a request with a true origin of user 1234 and one forged by an API server misusing its shared credential.
The credentials used to prove and verify the origin of an API request must be asymmetrical, with different credentials for each party. By doing this, we ensure the user is the only party with access to the credential.
  1. Which requirement isn’t met by a shared secret between client and server?
Nonrepudiation
  1. Why is it important for the request fingerprint to include the HTTP method, host, and path attributes?
We should include information about action of the request, target resource of the request, and the destination host for the request.
  1. Are the digital signatures laid out in this pattern susceptible to replay attacks? If so, how can this be addressed?
Yes. We should include an indication of the time at which the request was sent; most often this is present in a HTTP header called “Date” in order to support rejecting requests that might be too old.

Summary

  • There are three requirements for successful request authentication: proof of origin, proof of integrity, and prevention of repudiation.

  • Origin is the proof that a request came from a known source, without any uncertainty.

  • Integrity is focused on ensuring that the request itself has not been tampered with from the time it was sent from the known origin.

  • Nonrepudiation refers to the inability of the requester to later claim the request was actually sent from someone else.

  • Unlike real-world identity, authentication relies on identity being defined as possession of a secret key, sort of like a bearer bond.

  • When signing a request, the actual content being signed should be a fingerprint of the request, including the HTTP method, path, host, and a set of content in the HTTP body.