Tips & Tricks, Visual Studio Team Services

VSTS PAT used for Build Agent expires, now what?

When using Visual Studio Team Services (VSTS) and Build/Release Agents, the way to authenticate is through Personal Access Tokens (PAT). A PAT can either expire in 90 days, 180 days or 1 year. The question is: what happens after expiration with my Build/Release Agent? Will it stop working? What if I restart it after expiration?

Luckily, the Agent will still work! Behind the scenes, Microsoft uses a different mechanism to authenticate. This is an answer from a Microsoft employee on MSDN forums (source: https://social.msdn.microsoft.com/Forums/en-US/431f9a06-db69-49d4-8bc0-3bff9911f959/vsts-private-agent-authentication-with-pat-personal-access-tokens)

For security reasons, we don’t want to persist your PAT on the agent machines.  The PAT is only used to register the agent.  Upon registering we generate a JWT token specifically for that agent which only has permissions to listen to the queue.  That JWT token is encrypted / stored securely and has limited rights.

The build machine uses that JWT token to listen to the queue.  When the server runs a build, it generates another time bombed (life of the build) token which allows the build machine to get sources and write back to VSTS / TFS.  The token represents to a collection or project level service account (see options tab on definition).  That token is never persisted and only held by the agent and available to tasks.  There is also an option to expose that token to ad-hoc scripts (ps1, cmd, sh).

If you use agent config.cmd remove, that’s why it will prompt you for the PAT again.  Because we didn’t store it.  That’s the one down side.  But, you can always remove the agent from the web UI and wack the agent folder if you’ve revoked the PAT.

Furthermore, Microsoft is improving the experience of PAT (and other alternate authentication): https://blogs.msdn.microsoft.com/devops/2017/07/14/improved-alternate-authentication-experience/

 

Leave a comment