Authentication verifies that an inbound API request came from the user it claims, was not modified, and cannot later be repudiated. Digital signatures satisfy these requirements by proving possession of a private key, binding the signature to the request, and making the signer uniquely responsible for its creation. section 30.1 section 30.2
A public-key authentication flow proceeds as follows:
- Create a public-private keypair. section 30.2
- Register the public key with the API, which assigns a unique user identifier. section 30.3.2
- Sign each request with the private key; the server selects the registered public key and verifies the signature. section 30.2
- Build the signed fingerprint from the HTTP method, path, host, and selected request content, including a body digest where applicable. section 30.6
- Keep the configured fingerprint header order consistent; the physical order of HTTP headers does not matter. section 30.3.5
Signing a PATCH request
A request updating chat room 1 can carry a SHA-256 digest for its JSON body and a signature identifying user 1234, the rsa-sha256 algorithm, and the ordered components `(request-target)`, `host`, `date`, and `digest`. The server verifies the digest and signature before accepting the update. section 30.3.5 section 30.6
Figure 30.1 Sequence of registering an account with a public key
Use the registration sequence to trace how a public key establishes an API identity before signed requests begin. section 30.3.2
