Recently, the Azure DevOps team completed an initiative to associate all Azure DevOps REST APIs with a granular personal access token (PAT) scope. As part of our ongoing investments in security, we undertook this effort to reduce the risks associated with a leaked PAT credential. Previously, a number of Azure DevOps REST APIs were not associated with a PAT scope, which at times led customers to consume these APIs using full-scoped PATs. The broad permissions of a full-scoped PAT (all permissions of their corresponding user), in the hands of a malicious actor, represent a significant security risk to organizations, given the potential to access source code, production infrastructure, and other valuable assets.
If you are currently using a full-scoped PAT to authenticate to one of the Azure DevOps REST APIs, consider migrating to a PAT with the specific scope accepted by the API to avoid unnecessary access. The supported granular PAT scope(s) for a given REST API can be found in the Security -> Scopes section of the REST API documentation pages.
Moreover, these improvements should allow even more customers to restrict creation of full-scoped PATs by enabling the corresponding control plane policy.
We look forward to continuing to ship improvements which will help customers secure their DevOps environments. As always, if you have questions or feedback, feel free to share below.
This will be awesome once application (non-delegated) scopes are supported!
Does this apply to the Work Item Batch Update API? There is still a documentation issue where this does not show up in the latest version of the docs. Additionally, this was an API that required fully scoped PATs. Is that no longer the case now for this API?
https://github.com/MicrosoftDocs/vsts-rest-api-specs/issues/455
Yes. Although the docs issue has not yet been fixed, the Work Item Batch Update API can now be accessed with PATs that have scope vso.work_write