Using Workload Identity Federation for Azure DevOps Service Connections

A step-by-step guide on creating manual workload identity federation service connection in Azure DevOps which is now a recommended way to create service connections.

If you have ever previously created service connections which relied on PAT (Personal Access Token) in Azure DevOps to deploy to Azure, you know the pain of trying to trigger the build/release pipeline and it failing due to expired PAT.

Not only PAT are less secure, but they also end up giving broader permission to anyone who has access to PAT or the person who created the service connection.

With Azure DevOps now supporting Workload Identity federation, both of those issues can be addressed. So you now can have service connections

1. Which do not suffer the problem of expiring PAT (they internally use short-lived tokens to connect to Azure)
2. Can only be accessed by Azure DevOps

If you are interested in knowing more about how Workload identification works, refer to the documentation (I am posting a diagram below from docs if you want a quick sequence of steps).