In the dynamic landscape of modern web applications and organizations, access control is critical. Defining who can do what within your Cloudflare account ensures security and efficient workflow management. As Cloudflare offers a greater variety of products, the possible combinations of access controls we offer need to improve to meet all use cases.
Today, we are announcing the open beta for Account Owned Tokens, which is a step in the direction of providing service principals to our customers.
What Credentials exist today, and for which use cases?
Cloudflare customers are able to access Cloudflare services through several interfaces, this includes interactively (through the dashboard), via Wrangler, as well as through our API. In each of these cases, we need to ensure that we can provide authentication and authorization via appropriate sets of credentials.
For interactive access, generally this means either: Username and Password with a Passkey or mobile authenticator, social login, or a single sign on back to your company’s IDP.
In the case of the Cloudflare API, two types of credentials are accepted:
API Tokens are the preferred credential, allowing anyone holding them to use a specifically delegated subset of your user’s permissions. These tokens act as bearer tokens, with a single string providing authentication, and allowing Cloudflare to look up the appropriate authorization attached to the token. They have the capability to be edited, rolled (invalidating the old value and producing a new value), as well as being deleted.
API Keys are used to delegate the whole of a user’s access, and require both an email, as well as the key itself in the header of the API request. One key exists per user, and the value can be changed, but it cannot be deleted.
What is new about Account Owned Tokens
API Tokens created today are restricted by the creating user’s active permissions and policies applied via Account Memberships. (A user with read-only access to an account can create a token with a write permission, but that token will not have that permission at runtime).
Account Owned Tokens are not confined by the policies of the creating user and are scoped to the account they are owned by.They can be used to represent access for any long running services or programs that rely on Cloudflare services. This could range from part of your CI/CD pipeline making changes to Cloudflare workers, anything programmatic that changes your Cloudflare configuration, or a service that takes advantage of Cloudflare R2 Bucket storage.
Account Owned Tokens can be found on the new “API Tokens” tab under the “Manage Account” section of your Cloudflare dashboard, and any Super Administrators on your account have the capability to create, edit, roll, and delete these tokens. These tokens can be created with the exact same interface (both UI and API) as any older flavor of user tokens and with the same capabilities to set an IP address filtering, appropriate permissions, and a TTL value.
The API is the same API, but at a new /account//tokens endpoint.
Why should I use Account Owned Tokens?
There are a few reasons Account Owned Tokens make sense over user owned tokens:
- They provide business continuity, and de-link access from users.
Putting a token behind a real user, even if it was pulled out of Cloudflare and placed into your local secret store, reduces the ability for those managing your service to be able to get to it and action it in a way that preserves business continuity.
If the user that created the token that manages a service goes on vacation, and the token suddenly expires or is leaked, having an Account Owned Token means that any Super Administrator on the account can make edits, or roll the token, where this previously may have been a call to somebody out of office.
If the user that created the token suddenly changes roles and has their Cloudflare permissions removed or downgraded, previously, this would have meant the token would stop working against the API. Account Owned Tokens are bound by the account’s inherent permissions to its resources, meaning that user lifecycle events can be abstracted from your deployment plans.
- They allow for better visibility, control, and management of your account, especially when used with Account API restrictions
Cloudflare provides the capability for our customers to gate access to our configuration Dashboard and API separately. A problem that arose for many customers was that the API Tokens that controlled API access were unmanageable due to their tight coupling to our User profile. Organization administrators lacked the observability they needed to manage their access.
Now, when Account Owned Tokens are used with the “Enable API Access” toggle, account Super Administrators can block ALL access to the API except via centrally managed Account Owned Tokens, or even allow only a certain number of users continued API access.
- They decrease the potential attack surface by reducing the need for “Service Users”
A pattern we have observed across some of our customers is the presence of “service users” when they are trying to abstract their access away from users to avoid the two issues brought up above. These “service users” are generally an identity on the Cloudflare dashboard that isn’t tied to a single real person, generally have high levels of access, and need to be accessible by multiple people in real life, complicating multi factor authentication setup.
These “service users” are a high value target for malicious actors, and adopting Account Owned Tokens will allow for this access to be instead stored on the account itself.
What does “Open Beta” mean?
During the Open Beta period our team is working hard internally to provide as much Account Owned Token compatibility as possible. Engineers across the company are working together to ensure products you care about are covered prior to our full release in October.
User tokens will continue to be available and usable for any scenario that Account Owned Tokens are not currently supported, and we will be posting updates on both the Cloudflare Blog, and our documentation moving forward.
We are in the process of creating, and updating the information available in our documentation about what will and won’t work. We have targeted our most popular endpoints first, in order to ensure that the majority of our users are able to get the maximum amount of value out of Account Owned Tokens.
What’s next?
We will be posting updates around Account Owned Tokens compatibility as we approach being generally available, and will be developing further access controls to ensure our customers are able to scope access to organizations’ needs. If you are a customer that can see real value from Account Owned Tokens, give them a try today from the “API Tokens” menu in your dashboard.