There is no reason not to switch to Workload Identity Federation for Service Connections in Azure DevOps. Compared to secret-based connections, it offers several compelling benefits:

• Firstly, you eliminate the need for secrets. This means no more manual or automatic rotation of secrets, or worse, being caught off guard when secrets expire unnoticed.
• Secondly, it’s more secure. Secrets used across multiple projects and stored in key vaults or, even worse, in tools like OneNote, are far more susceptible to compromise than the new identity federation approach.

Here is my step-by-step guide on setting up Workload Identity Federation in Azure DevOps. I recommend the manual setup over the automatic one for these reasons:

The new permission in Graph API - Sites.Selected - is a step in the right direction. Since long we have been looking for ways of scoping the accesses to live up to the least privilege principle. It was either nothing or everything. I have tried out the new Sites.Selected permission and here are my findings.

First of all, if you haven’t heard about Sites.Selected, please visit these pages to find out more. I am skipping the introduction, since there are already good resources on that out there.