As part of our ongoing commitment to meeting the Security & Compliance needs of our customers, Bitbucket Cloud is introducing the first of a range of new API access controls.

We understand there is a constant tension between the need to keep source code secure, while also enabling tools to integrate with your Source Code Management solution. In line with this, Bitbucket Cloud is introducing the first step in a range of new API security capabilities, designed to give customers fine-grained control over access to their Repositories, Projects, and Workspaces. The goal of these new capabilities is to give customers the tools they need to ensure the security of their code, while also scaling their administration of Bitbucket Cloud to better align with the needs of large & enterprise customers.

From user-based access controls…

Today, in Bitbucket Cloud, the primary method to authenticate with the Bitbucket Cloud REST API is via App Passwords. While App Passwords are an excellent solution to many challenges users face, they do have some limitations when it comes to managing API access from the perspective of an overall organization, rather than an individual user.

To put it simply, users change; they change teams, change projects, and even change companies. This means that API controls that are inherently tied to a user, such as App Passwords, will also change – and that’s by design. However, given a users access can be changed over time, their app passwords are also impacted by these changes, which can increase the security impact if the token is exposed. It can also lead to broken integrations and automations if the level of access granted to a particular token changes, breaking the workflow that the token was being used inside. Again, this direct connection to the user is a good thing, when the API control is being used in a scenario where it’s meant to represent that user, but that isn’t always the situation.

To resource-based access controls.

Today, Bitbucket Cloud is introducing a new type of API Control called a Repository Access Token. This is a new API Token, similar in functionality to App Passwords, but completely disconnected from any particular user or account. Instead, this token is tied to a specific Repository.

Customers will be able to create unique tokens on a repository-by-repository basis. This allows API & Git access to be granted that is scoped solely to the repository the API Token was associated with, as well as its respective lower-level features such as Pull Requests & Pipeline Runners. This will provide customers with a range of benefits, including fine-grained access control and access that is decoupled from users.

Fine-grained access control.

Repository Access Tokens allow customers to enable access to the Bitbucket Cloud REST API in a fine-grained way. Take the example of a CI/CD Pipeline where a step in the overall process needs to communicate with Bitbucket Cloud through the API. Customers are now able to generate an API Token that grants access solely to the repository that the pipeline interacts with, significantly reducing the risk if that token were to ever leak.

Decoupling from users.

As mentioned previously, users change. Their permissions can be updated, they can change teams, or they might even leave a company altogether. This creates a problem if integrations or automations have been built that utilize API controls tied to a specific user. If the user loses access to the respective repositories that automation or integration works with, the integration will no longer function the way it is expected to.

This is by design if the integration is representing that user, but not if the integration is designed to be long-lived and is “resource-based”, rather than “user-based”.

Repository Access Tokens allow customers to meet this more “resource-specific” use case with a dedicated, long-lived API Token that is scoped solely to the repository in question and is completely decoupled from any particular user. These new tokens are treated as extensions of the repository configuration and are managed by the respective repository admins.

So what’s next?

As hinted at during this post, this is just the first of a series of new API Controls that are on their way. We plan to expand on the concept of “resource-based” Access Controls over the next few months to include Project Access Tokens and Workspace Access Tokens so that customers can have the benefits of added security and maintainability, while also being able to scale the administration of these new tokens across larger organizations. Customer feedback is a critical piece of this process so please get in touch with us through the Atlassian Community to share your thoughts/insights and stay tuned for more in this space over the coming months.