Access tokens

Replace tokens before they expire

To avoid losing access to EdgeKV from an EdgeWorker ID due to an expired token, you need to generate a new token before the existing one expires. You then need to update your edgekv_tokens.js file(s) with the new token and upload and activate the associated EdgeWorker bundles. Your EdgeKV calls will fail if an expired token is not replaced in time, and you will receive a 401 error when using an expired token.

To monitor the expiry date of your access tokens, you can use the EdgeKV CLI List and Retrieve commands or the EdgeKV List and Retrieve management APIs.

Store access tokens securely

Rely on Akamai to keep your access tokens stored securely, and only retrieve them as needed. Do not store access tokens in your own systems, except in transient storage. For example, you can temporarily store an access token on your local filesystem until you have created and uploaded an EdgeWorker bundle, after which we recommend that you delete the local copy.

Comply with your corporate security standards

If you have stringent corporate security requirements, consider implementing one or more of the following best practices to further restrict access to your EdgeKV data:

Limit access token permissions

Be specific with the namespace permissions in the token. If, for example, your EdgeWorkers code does not require delete or write access to your “marketing” namespace, grant it read-only access in the token:

edgekv create token token1 --staging=allow --production=allow \
    --namespace=default+rwd,marketing+r --expiry=2021-12-31

This reduces the likelihood of inadvertent writes or deletes being made to the database.

Separate tokens

Another good practice is to use single-purpose tokens: create a separate token for every unique use case for a given namespace. This provides an additional layer of isolation.


This feature notifies you when your access tokens are nearing expiration. Be sure to subscribe to those notifications so you can replace your tokens well ahead of expiry.

Limit access tokens to a namespace

To add another layer of security to EdgeKV you can specify an access group for each namespace. This access group can then be restricted to specific individuals in your organization.

You should associate any EdgeWorker IDs that you create with the same access group as the namespace it uses. This prevents unauthorized users from downloading the token indirectly via the EdgeWorkers code bundle.

For example, if only EdgeWorker ID 1234 requires access to the “marketing” namespace you should first create access group 100 specifically for the marketing use case. Then create EdgeWorker ID 1234 under group 100. You should also create the marketing namespace under group 100. This prevents individuals that don't belong to group 100 from retrieving the access token(s) associated with the marketing namespace via the EdgeKV tools, or indirectly by downloading the code bundle.

For more information about groups refer to the Identity and Access Management documentation.

Lock an access token to specific EdgeWorker IDs

You can lock an access token to one or more specific EdgeWorker IDs. For example, if only EdgeWorker ID 1234 needs to access the namespace “marketing” you would:

  • Create a token specific to that use case.
  • Restrict the EdgeWorker ID in the token permissions list.
  • Only include the “marketing” namespace in the permissions.
edgekv create token mkt_token1 --staging=allow --production=deny \
    --ewids=1234 --namespace=marketing+r --expiry=2021-12-31

Coming soon - Isolate your staging and production environments

In the future you'll be able to use your CI/CD system to separate your production and staging workflows. This will let you create separate API client credentials for your developers and grant them permission to access only to the staging environment, while creating another API client credential for your CI/CD system and granting it permissions to access to your production environment.

You should also consider creating separate tokens for the production and staging environments whereby the staging one can be retrieved by developers and the production one can be retrieved by the CI/CD system.

Combining these will restrict your developers access to only the staging environment, while allowing your CI/CD system to access production.

To create a specific tokens for the staging and production environments:

edgekv create token mkt_token1_prd --staging=deny \
    --production=allow --ewids=1234 \
    --namespace=marketing+r --expiry=2021-12-31
edgekv create token mkt_token1_stg --staging=allow \
    --production=deny --ewids=1234 \
    --namespace=marketing+r --expiry=2021-12-31