Concepts / API Keys and Basic Authentication

API Keys and Basic Authentication

Simple API key authentication is sufficient in many situations where the main concern is identifying who is making the request.

  • Programming

Why Request Integrity Matters

An API request can contain more than an identity claim. Its parameters can also specify an action, an amount, or the resource being accessed. For many ordinary requests, a vendor mainly needs to know who has the API key. For sensitive operations, the vendor may also need assurance that the request was not changed while traveling to the server. Cryptographically signed messages provide this additional assurance: they help verify both the source of the request and whether the request was altered in transit.

Request messageTransfer 100 dollarsMathematicalalgorithmCombines message and secretSignatureSent with requestServer verificationRecomputed signaturematchesRequest acceptedShared secretKnown by client and serverRequest rejectedcombinecombineproducecomparematchmismatch
How does a vendor use a shared secret to determine who sent a request and whether the request changed in transit?

Constructing a Signed Request

A signed request begins with the request message and a shared secret key. The client combines them using a mathematical algorithm to create a signature. The client sends the request and the signature to the vendor. The secret itself is not the item being sent as the signature; instead, both parties use their knowledge of the shared secret to participate in creating or checking the signature. The server independently recomputes the signature from the received request and its copy of the shared secret. If the recomputed result matches the signature sent with the request, the signature supports two conclusions: the request came from someone holding the secret, and the request has not been changed since it was signed.

ClientRequest messageParameters and actionSignatureCreated with shared secretRequest and signatureRecomputed signatureCreated by serverSignature comparisonVerification resultAccept or rejectVendor serverconstructscombine with secretsend with requestarrives atrecomputecompareprovided signaturedetermine
What happens next as a client constructs a request, creates a signature, sends it, and the vendor verifies it?

The Shared Secret

Definition

A shared secret is confidential information known by both the client and the server. It is combined with a request message through a mathematical algorithm to create a signature, and the server uses its copy to recompute and verify that signature.

ClientRequest message and sharedsecretShared secretKept confidentialSignatureSent with requestVerificationRecomputed and comparedVendor serverRequest message and sharedsecretholdsholdshelps createis checked
What does each party contain, and how do the client and vendor use the same secret without sending that secret in the request?

A Changed Transfer Request

Worked example

Detecting a Modified Amount

A client sends a request to transfer 100 dollars to account 5678. The client signs the request with a secret key. An attacker changes the amount to 10,000 dollars and forwards the changed request with the original signature.

  1. 1
    Original signing

    The client combines the original transfer request and the secret key using a mathematical algorithm, producing a signature.

  2. 2
    Interception

    The attacker changes the transfer amount but does not know the secret key.

  3. 3
    Server recomputation

    The bank verifies the received request by recomputing the signature with the changed message and its copy of the secret key.

  4. 4
    Comparison

    The changed message produces a result that does not match the original signature.

  5. 5
    Decision

    The verification fails, so the bank rejects the request and the fraudulent transfer is prevented.

Result

A signature protects the integrity of the signed request because changing the message without the secret key prevents the attacker from producing a matching signature.

What do you think happens?

If an attacker changes a signed transfer from 100 dollars to 10,000 dollars but keeps the original signature, what should the vendor do?

  • Accept the request because the API key or signature is present

  • Reject the request because the recomputed signature does not match

  • Accept the request and use the original amount

Reveal answer
Answer:

Reject the request because the recomputed signature does not match.

The server recomputes the signature from the changed message and its copy of the shared secret. Because the message changed but the original signature did not, verification fails.

100 dollarsAccount 567810,000 dollarsAccount 5678Verification failureRequest rejectedOriginal signatureOriginal signaturesigneddoes not matchchecked by server
What changes when an attacker alters a signed request without knowing the shared secret?

API Keys Versus Signed Requests

ApproachWhat the server can establishWhat it cannot establish from this method aloneTypical use
API key authenticationThe request came from someone who has the API keyThat the request was not modified in transitUse cases where identifying the requester is the main concern
Cryptographically signed requestThe request came from someone holding the shared secret and the request matches the signatureNothing beyond the assurance provided by the signature processSensitive data changes, financial transactions, or protected resources

The key distinction is whether the server can verify request integrity as well as possession of a credential.

When a request contains only an API key, the server knows that whoever sent it possesses that key. However, an attacker could intercept the request, change its parameters, and forward it while leaving the API key present. The server would still accept the request because the key is present. A signed request adds an integrity check: changing the message makes the original signature fail verification.

API keyCredential sent withrequestKey possessionServer checks keyRequester identifiedModification not verifiedRequest andsignatureSignature based on messageand secretSignature comparisonServer recomputes signatureSource and integrityBoth supported byverificationchecksupportschecksupports
What is different about the data sent, the checks performed, and the assurance provided by an API key versus a cryptographically signed request?

Choosing the Protection Level

API requestSensitive operationFinancial, protected, ordata-modifyingAPI keyauthenticationIdentifies requesterCryptographicallysigned requestAdds source and integrityassuranceassessnoyes
How can a decision process determine whether a basic API key is sufficient or a signed request is needed?

Not every request needs a signature. Simple API key authentication is sufficient in many situations where the main concern is identifying who is making the request. A vendor is more likely to require cryptographic signing when the API modifies sensitive data, performs financial transactions, or provides access to protected resources. In those cases, the vendor wants evidence that the requester is authorized and that the request was not altered in transit.

OAuth is a widely used standard technology for signing requests over the Internet. It belongs in the same request-security discussion because it is a recognized way to support signed Internet requests; the underlying assurance still depends on the credentials and secrets used by the participants being kept confidential.

ClientCredentials andsecretsSigned requestRequest with signatureAPI providerVerifies requestOAuthStandard technologyusessupportssigning technology forsent to
Where does OAuth fit in the request flow, and how does it connect clients, credentials, signatures, and API providers?

Mistakes That Weaken Authentication

  • Common mistake

    Treating an API key as proof that the request was not modified.

    What it looks like

    A client sends an API key with a request, and an attacker changes the request parameters before forwarding it.

    Why it fails

    An API key shows that the sender has the key, but the server cannot verify from the API key alone that the request was unchanged in transit.

    Do this instead

    Use a cryptographically signed request when the vendor needs assurance about both the source and integrity of the request.

  • Common mistake

    Sending or exposing the shared secret carelessly.

    What it looks like

    A secret is committed to version control, written to logs, or shared over an unencrypted channel.

    Why it fails

    Anyone who learns the secret can forge signatures and create malicious requests that appear legitimate.

    Do this instead

    Keep the shared secret confidential and protect it as carefully as a password.

  • Common mistake

    Assuming every API request must be signed.

    What it looks like

    A developer chooses signed requests even when the only concern is identifying who is making a low-sensitivity request.

    Why it fails

    The source states that simple API key authentication is sufficient for many use cases.

    Do this instead

    Choose signing when the vendor needs increased assurance, especially for sensitive data, financial transactions, or protected resources.

Check Your Understanding

MEDIUM

A vendor offers an API that can either read ordinary information or initiate a financial transaction. Explain which authentication approach is more likely to be required for each operation and what assurance the signed approach adds.

Hints
  • Ask whether the main concern is identifying the requester or also detecting changes to the request.
  • Consider the source's treatment of financial transactions and protected resources.
  • State what the server recomputes and compares when a request is signed.
Worked example

Evaluating Two API Operations

Classify an ordinary information request and a financial transfer request according to whether simple API key authentication may be sufficient or whether a signed request provides important additional assurance.

  1. 1
    Ordinary information request

    If the main concern is identifying who is making the request, simple API key authentication may be sufficient.

  2. 2
    Financial transfer request

    A financial transaction is a situation in which the vendor may require a cryptographically signed message.

  3. 3
    Additional assurance

    The signature supports verification that the request came from someone holding the shared secret and that the request was not altered in transit.

Result

The appropriate approach depends on the assurance the operation requires, not on a rule that every request must use the same authentication method.

Key Takeaways

  1. 1
    An API key identifies a requester who possesses the key, but it does not by itself prove that request parameters were unchanged in transit.
  2. 2
    A signed request combines the message and a confidential shared secret through a mathematical algorithm to produce a signature.
  3. 3
    The server verifies a signed request by recomputing the signature and comparing it with the received signature.
  4. 4
    A valid signature supports assurance about both the request source and the request's integrity.
  5. 5
    Simple API key authentication may be sufficient for many use cases, while sensitive data changes, financial transactions, and protected resources may require signed requests.
  6. 6
    OAuth is a widely used standard technology for signing requests over the Internet.

At a glance

  • API keys show possession of a credential, but they do not by themselves verify that a request was unchanged in transit.
  • Signed requests use a shared secret and a mathematical algorithm to create a signature tied to the request message.
  • The server recomputes and compares the signature; a changed message causes verification to fail when the attacker cannot create a new valid signature.
  • Shared secrets must remain confidential because anyone who learns one can forge signatures.
  • Signed requests are especially useful for sensitive data changes, financial transactions, and protected resources, and OAuth is a widely used technology for signing Internet requests.

Related concepts

More concepts starting with A