Authorization and Access Control
Vendors require cryptographically signed messages to verify both the source of requests and that they have not been altered in transit.
Why Request Authorization Needs More Than Identity
When a vendor receives an API request, it may need to answer two questions: who sent the request, and whether the request changed while traveling to the server. A simple API key can show that the sender possesses the key, but it does not allow the server to verify that the request itself remained unchanged. Cryptographically signed messages address both concerns.
How a Shared Secret Produces a Signature
The client and the server share a secret key. To create a signature, the client combines the request message with that shared secret and applies a mathematical algorithm. The client sends the request together with the resulting signature. The server uses the shared secret and the received request to recompute the signature. It then compares the recomputed result with the signature that arrived with the request.
A matching signature provides two assurances: the request came from the holder of the shared secret, and the request has not been altered since it was signed. If the message changes but the signature does not, the server's recomputed signature differs from the received signature.
A Fund Transfer That Fails Verification
Protecting the Transfer Amount
A client sends a fund transfer request asking a bank API to transfer 100 dollars to account 5678. The client signs the request with its secret key. An attacker intercepts the request, changes the amount to 10,000 dollars, and forwards the changed request with the original signature.
Original signing: The client combines the original transfer request with its secret key and produces a signature.
Message alteration: The attacker changes the transfer amount, but does not know the secret key and therefore cannot recompute a signature for the changed message.
Server verification: The bank server uses the received request and the secret key to recompute the signature. The changed request produces a different result from the original signature.
Decision: Because verification fails, the bank rejects the request and the fraudulent transfer is prevented.
The modified request is rejected because the message and its original signature no longer correspond.
The signature does not stop someone from attempting to alter a message in transit. Its value is that the server can detect the alteration when it recomputes the signature. The altered request cannot pass verification unless the attacker also knows the shared secret.
OAuth and Internet Request Signing
OAuth is a widely used standard technology for signing requests over the Internet. In the context of this topic, OAuth belongs to the family of approaches that help a client send an authorized request with information the server can verify. The essential idea remains the same: the vendor needs a way to check the request's source and whether its contents were altered.
API Keys Compared with Signed Requests
| Authentication approach | What the server can establish | What it cannot establish from that information alone | Typical fit |
|---|---|---|---|
| API key | The request came from someone who has the API key | Whether the request was modified in transit | Use cases where identifying the requester is the main concern |
| Cryptographically signed request | The request came from the holder of the shared secret and matches the signed message | No additional claim beyond the assurances provided by the signing process | Requests that modify sensitive data, perform financial transactions, or access protected resources |
Protecting Shared Secrets
The security of a signed request depends entirely on the secrecy of the shared key. Both the client and the server must know it, but no one else should. Someone who learns the secret can create signatures for malicious requests that the server may accept as legitimate.
Hardcoding a shared secret in application code.
The source may expose the secret to people or systems that should not know it.
Fix:
Keep shared secrets confidential and do not commit them to version control.Logging a shared secret.
Logs can expose the secret to anyone who can access them.
Fix:
Do not log shared secrets.Transmitting a shared secret over an unencrypted channel.
An attacker may learn the secret and forge signatures.
Fix:
Never share shared secrets over unencrypted channels.
Practice the Verification Decision
A request contains a valid API key, but its parameters were changed after the client sent it. Should a server using only simple API key authentication be able to detect that change? What additional information would a signed-request system use?
Hints
- Ask what an API key proves by itself.
- Then consider what the server recomputes from the request and the shared secret.
What do you think happens?
The request message changes after signing, but the original signature remains attached. What should the vendor do?
Reveal answer
Answer: Reject the request because recomputation will not match the received signature.
The server recomputes the signature from the changed message and the shared secret. Because the message is different, the result differs from the original signature.
Key Takeaways
- A cryptographically signed request helps a vendor verify both the source of the request and whether the message was altered in transit.
- The client creates a signature by combining the request with a shared secret and applying a mathematical algorithm.
- The server verifies the request by recomputing the signature and comparing it with the received signature.
- OAuth is a widely used standard technology for signing requests over the Internet.
- Simple API keys may be sufficient when identifying the requester is the main concern, while signed requests provide important additional assurance for sensitive or financial operations.
- Shared secrets must remain confidential: they must not be hardcoded, logged, or transmitted over unencrypted channels.
Key Takeaways
- Signed requests verify the source of a request and the integrity of its message.
- A shared secret is used by both client and server to create and recompute the signature.
- Changing a signed request without knowing the secret causes verification to fail.
- API keys identify someone who possesses the key but do not by themselves prove that request parameters were unchanged.
- OAuth is a widely used technology for signing requests over the Internet.