Origin authentication is how Akamai edge servers prove to your origin that a forward request came from your Delivery Manager configuration. You select a method when you add an origin or edit an origin.

📘

Two different kinds of trust

Origin authentication proves the edge server to your origin. Origin SSL certificate verification does the reverse, proving your origin to the edge server. They're configured separately and most secure setups use both. For certificate verification, see Configure origin settings.

Choose a method

Every method except None is configured the same way in Delivery Manager: select the method, then select an Access key. Delivery Manager stores no credentials. The key identifier and secret live in Cloud Access Manager, stay encrypted there, and edge servers apply them on the forward path.

Selecting None doesn't make your origin public, but at the same time Akamai doesn't send anything your origin can use to tell Akamai traffic from anything else. If you select None for an origin you own, restrict access another way. See Protect an origin with no authentication.

Before you select any method

Create an access key first. Four things determine whether the key you create is selectable on your origin.

If the Access key list shows There are no items to display, no key on this contract matches the method you just selected. Work through the four rows above before assuming the key is broken.

🚧

Record the credentials at creation time

Cloud Access Manager shows the access key identifier and secret only while you're creating the key. Afterwards the secret is encrypted and not visible, including to Akamai. To change either value, create a new version of the key.

You're limited to 50 access keys per contract and two versions per key. If you reach the limit, delete a key or a key version before creating another.

Akamai Signature Header Authentication

Also known as G2O. Edge servers sign every forward request with a secret shared between Akamai and your origin. Your origin recomputes the signature and rejects requests that don't match, so a client that discovers your origin hostname and requests content directly gets nothing.

This is the method to use when you own the origin and want application-level proof of Akamai traffic, rather than relying on firewall rules alone.

Unlike the cloud storage methods, this one needs work on your origin. Nothing in Delivery Manager validates the signature for you. See Prepare your origin below.

Create the access key

Create the key in Cloud Access Manager with the Akamai Signature Header Authentication (G2O) authentication method, then select it on your origin. The two credential fields map onto G2O as follows.

🚧

The access key ID isn't a secret

It's sent in clear text on every request. Only the secret is confidential. Never set the access key ID to the same value as the secret, and never log the sign header next to the secret.

Generate the secret randomly and don't reuse it across origins. An origin that shares a secret with another origin can't be rotated independently.

How the signature works

Edge servers add two headers to each forward request.

The data header holds six elements in this order.

A complete data header looks like this.

X-Akamai-G2O-Auth-Data: 5, 23.50.50.13, 64.124.137.130, 1738191250, 4545696.900708813, 1b4ead

The sign header is the base64-encoded keyed hash of the data header concatenated with the signed string, computed with your secret.

sign = base64_encode(hmac(algorithm, secret_key, data_header + signed_string))

The signed string is the forward URL, meaning the path and query string sent to your origin. The signature therefore covers the specific object requested, so a captured signature can't be replayed against a different path.

Encryption algorithm versions

The version number is the first element of the data header, so your origin can read it before choosing how to verify.

Delivery Manager doesn't expose an algorithm setting when you add an origin. Have your origin read the version from the first element of the data header and verify with the matching algorithm, rather than hard-coding one. An origin written that way keeps working if the platform default changes.

Prepare your origin

Your origin has to validate the signature. Implement the following on the origin, or in a module or middleware in front of it.

1. Read X-Akamai-G2O-Auth-Data and X-Akamai-G2O-Auth-Sign. Reject the request if either is absent.
2. Take the key identifier from the sixth element of the data header and look up the matching secret. Reject the request if the identifier is unknown.
3. Recompute the signature over the data header concatenated with the signed string, using the algorithm named by the version element.
4. Compare your result with the sign header using a constant-time comparison, so your code doesn't leak the secret through response timing.
5. Check that the timestamp in the fourth element is within a short window of your current time, to limit replay. Keep your origin's clock synchronized, or valid requests will fail.
6. Optionally, record the unique request identifier for the length of that window and reject repeats, to close the replay window completely.

🚧

Roll it out in the right order

Enable validation on your origin in a permissive mode first, logging failures without rejecting, and activate the Delivery Manager change on staging. Only enforce rejection once you've confirmed that signatures validate. An origin that enforces validation before edge servers start signing rejects all Akamai traffic. See Test on staging.

Rotate the secret

Rotate by creating a new version of the access key in Cloud Access Manager rather than creating a separate key. Your origin keeps referencing the same key by name, so no Delivery Manager change or reactivation is needed.

The new version doesn't reach every edge server at the same instant, so your origin has to accept both secrets during the changeover.

1. Configure your origin to accept both the current and the new secret, each under its own key identifier. Because the key identifier travels in the data header, your origin can tell which secret to apply per request.
2. Create the new access key version in Cloud Access Manager.
3. Wait for activation, then confirm on staging that requests signed with the new version validate.
4. Once production traffic is stable, remove the old secret from your origin.

Don't skip step 1. An origin that accepts only one secret rejects every request signed with the other one during the changeover.

Access key methods for cloud storage

Amazon Web Services, Interoperability Google Cloud Storage, and Akamai Object Storage all work the same way. Edge servers sign each forward request with credentials held in Cloud Access Manager, using the signature version 4 signing process, and the storage provider authorizes the request. Your bucket stays private, and no credentials are stored in your Delivery Manager configuration.

Unlike G2O, these need no work on your origin. The provider already implements the verification.

For the signing processes themselves, see V4 signing process in AWS and V4 signing process in Google Cloud Storage.

For these methods, the Cloud Access Manager Access key ID and Secret access key are the credentials issued by your cloud provider, not values you invent. Rotating or revoking them at the provider without creating a new key version in Cloud Access Manager breaks signing.

Rotate a cloud storage access key

Create a new version of the existing access key in Cloud Access Manager. The origin keeps referencing the key by name, so no change in Delivery Manager is required.

Protect an origin with no authentication

If you select None, your origin can't distinguish Akamai requests from direct ones at the application layer. Combine at least one of the following.

• Restrict by source. Configure your origin to accept connections only from Akamai edge servers. See access control list solutions.
• Keep your origin hostname obscure. Use a dedicated origin hostname containing a random string, so your origin isn't discoverable from your public domain name. See Prepare your origin server.
• Require mutual TLS, if your origin supports it.

Obscurity alone isn't protection. An origin hostname is published in public DNS and can be found. Treat a random origin hostname as a way to raise the cost of discovery, not as an access control.

Next steps

• Add an origin
• Configure origin settings
• Troubleshoot origin connections