Workflow identity federation of “federated credentials” as they are called in the Azure Portal are brand new in the Microsoft identity suite. As of writing they are still in preview.
What are they and how does it work? This will all be explained in the post below.
Why would you need federated credentials?
Managing secrets is hard, as I explained several times on this blog, like here. If you can get someone else to manage the credentials for you, you should go for that options and have the other party worry about the credentials.
What are these federated credentials?
Microsoft wrote a great description on Workload identity federation, but in my own words, it’s trusting some pre-configured (external) identity provider to request tokens for an application in Azure AD, while using the token from the external IDP instead of a client assertion. So instead of signing the token request with a certificate, you configure Azure AD to trust external tokens as if they where client assertions.
How do federated credentials actually work?
I like federated credentials
I really like the idea of federated credentials. This is a great example how important security management is. And using federated credentials allows you to secure stuff without knowing the secret. If you don’t have/manage a secret, it can never be extracted because there is nothing to extract.
Mind you that as of today (May 20th 2022), this is still in preview which means that you can try it out, but should not use it in any production workloads.