Control and governance around PAT in VSTS

Question

We are evaluating VSTS for an enterprise use. One of the challenges from security team is lack of control and governance around usage of PAT (personal access tokens) As I understand, any user can create one or more PAT and this PAT could be used from outside network to make REST API calls (or to connect with tools outside network) to VSTS to access information.

Have number of questions around this scenario and any insights/ workarounds from your experience are appreciated

• How is your organization handling this issue or has worked around this issue? Looking for options to get buy-in from security team. Has anyone ever approached Microsoft with this problem statement? I am sure there are many enterprise customers, wondering how did they tackle this issue.
• Is there a way to disable creation of PAT for all users? Don't see any option, but any workaround to enforce this.
• Is there a way to get list of all PATs across all users? Don't see any option in VSTS, but may be through a script of some sort

Thanks

Answer 1

Update

There is now an API to list which PATs have been created and the option for an admin to revoke PATs on behalf of their users:

GET https://vssps.dev.azure.com/{organization}/_apis/tokenadmin/personalaccesstokens/{subjectDescriptor}?api-version=5.0-preview.1

Response:

{
  "value": [
    {
      "clientId": "00000000-0000-0000-0000-000000000000",
      "accessId": "00000000-0000-0000-0000-000000000000",
      "authorizationId": "952858d3-7084-4635-964e-3c2a57645185",
      "hostAuthorizationId": "00000000-0000-0000-0000-000000000000",
      "userId": "bb5bb6c8-ef0a-400f-8987-92b3674d2043",
      "validFrom": "2018-07-19T00:00:00",
      "validTo": "2018-07-19T00:00:00",
      "displayName": null,
      "scope": "app_token",
      "targetAccounts": null,
      "token": null,
      "alternateToken": null,
      "isValid": true,
      "isPublic": false,
      "publicData": null,
      "source": null
    },
    ....

More details here:

• https://learn.microsoft.com/en-us/rest/api/azure/devops/tokenadmin/personal%20access%20tokens/list?view=azure-devops-rest-5.0

And to revoke tokens of other users then use:

POST https://vssps.dev.azure.com/{organization}/_apis/tokenadmin/revocations?api-version=5.0-preview.1
[
  {
    "authorizationId": "532c7fe6-74f8-408b-8051-4abb73dca491"
  }
]

See:

• https://learn.microsoft.com/en-us/rest/api/azure/devops/tokenadmin/revocations/revoke%20authorizations?view=azure-devops-rest-5.0

---

There is an option to turn off Basic Credentials/Alternate authentication and SSH credentials, which are less secure than personal access tokens. There is no option to turn off Personal Access Tokens. I suppose the primary reason for this is that Git and the VSTS Agent infrastructure rely on these access tokens to work.

Since the Personal Access Tokens can be restricted in their scope, they're actually more secure than caching the user's credentials directly. They can also never give more permissions than the user already has.

You can't query all personal access tokens for all users, that would be a huge security violation. Exactly for the reason you're trying to restrict access to these tokens.

You can disable OAuth and Basic Credentials. This will not block Personal Access Tokens:

• https://learn.microsoft.com/en-us/vsts/accounts/change-application-access-policies-vs?view=vsts

Impact on Azure Conditional Access is explained here:

• https://learn.microsoft.com/en-us/vsts/accounts/manage-conditional-access?view=vsts

Important

VSTS only enforces conditional access policies when a user signs into services with their AAD credentials. Accessing VSTS using personal access tokens (PATs), alternate authentication, OAuth, and SSH keys circumvents conditional access policies.

Remember that when a person performs authentication using Azure Conditional Access and then leaves the building will be able to use that credential until it expires. In the end, security comes from education and monitoring, not from trying to put everything in an airtight container.

VSTS does keep an activity log which includes which users have performed which actions. This log will include the user's IP address. This way you can at least monitor the actions.