So, org is having me setup GitHub actions workflows for some new CI/CD stuff. Historically using ADO with Service Principal + client secret

I'm like cool. Clearly we'll use the azure/login action with OIDC. Most (all?) documentation concerning federated credentialsa and configuring this use managed identities Example

I spent about a day digging into how a UMI is just an abstraction over top a Service Principal and was like coolio, so unless I need client secrets or something, I'll just use UMI.

New guy joins and asks why not SP (he'd never used UMI before). I ask him to list differences as execise and then he starts to understand how the overlap was incredibly high and drops it. Decided to ask him to give it some more thought to see if he could make compelling case.....

Which brings me here:

The more I think about it, is there a case to use SPs for anything that supports federated credentials via UMI? Maybe I'm wrong but it seems clear that federated workload identies (as a concept) was made with Managed Identity in mind and added to SP after the fact.

It's a little weird to create a UMI unassigned to an Azure resource specifically for the purpose of GitHub (and eventually ADO) to use OIDC to reach an internal ACR and such. But it doesn't introduce any question on how auth is working, is right there next to all the other UMIs being used for other use cases, and I appreciate how it's a more limited resource (ie. no one will be accidently assigning secrets to it or something and forgetting about it)

Most research on the topic just repeats the adage of "use UMI for internal Azure resources and SP for external", but federated credentials clearly broke that paradigm over its knee and the documentation basically treats SPs as a legacy system best forgotten

edit:

also, when MSFT themselves have both their documentation and the portal UI all about quickly setting up UMI, I'm like "well clearly someone has a preference here"