Support federated credentials in on-behalf-of flow

[chlowell]

1P documentation shows how to authenticate the service principal in the OBO flow with a federated credential instead of a secret or certificate. The request is essentially the same as for a certificate, however its assertion is the federated credential instead of a JWT signed by the app. Note that the 3P documentation doesn't mention federated credentials, so this may be a 1P-only feature.

First thoughts on implementation:

1. check whether and how MSAL supports this
2. OBO constructor could take a callback providing assertions instead of a cert. This would be a dual-use in that it enables the federated credential scenario and also cert scenarios in which the client app doesn't possess the private key e.g. because it's stored in Key Vault

[joshfree]

/cc @scottaddie

[MRayermannMSFT]

Hi! Chiming in here to voice some 1P customer desire for this to be completed.

We run nodejs tests in our Azure pipelines, and these tests make API calls to Azure. Right now these API calls are authenticated using service principal secrets.

As part of a compliance effrot, we need to move away from using service principal secrets, and what seems to be the best way forward is federated credentials. We can connect service principals to our Azure pipelines using federated credential service connections, however, the @azure/identity package doesn't support federated credentials.

To be totally clear, we're looking for something that can provide an implementation of this OAuth flow:

Source: https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation

I believe this is something @azure/identity would expose (though I assume quite a bit of the acutal implementation would be coming from MSAL).

Additional information on our speceific scenario:

• Azure DevOps doc on setting up a service connection that uses federated credentials: https://learn.microsoft.com/en-us/azure/devops/pipelines/library/connect-to-azure?view=azure-devops#create-an-azure-resource-manager-service-connection-using-workload-identity-federation
• The Azure DevOps API for getting an oidc token, I believe this is something that we would have to provide as part of making a "federated credential" object: https://learn.microsoft.com/en-us/rest/api/azure/devops/distributedtask/oidctoken/create?view=azure-devops-rest-7.1

[maorleger]

Hi! Chiming in here to voice some 1P customer desire for this to be completed.

We run nodejs tests in our Azure pipelines, and these tests make API calls to Azure. Right now these API calls are authenticated using service principal secrets.

As part of a compliance effrot, we need to move away from using service principal secrets, and what seems to be the best way forward is federated credentials. We can connect service principals to our Azure pipelines using federated credential service connections, however, the @azure/identity package doesn't support federated credentials.

To be totally clear, we're looking for something that can provide an implementation of this OAuth flow:

Source: https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation

I believe this is something @azure/identity would expose (though I assume quite a bit of the acutal implementation would be coming from MSAL).

Additional information on our speceific scenario:

• Azure DevOps doc on setting up a service connection that uses federated credentials: https://learn.microsoft.com/en-us/azure/devops/pipelines/library/connect-to-azure?view=azure-devops#create-an-azure-resource-manager-service-connection-using-workload-identity-federation
• The Azure DevOps API for getting an oidc token, I believe this is something that we would have to provide as part of making a "federated credential" object: https://learn.microsoft.com/en-us/rest/api/azure/devops/distributedtask/oidctoken/create?view=azure-devops-rest-7.1

I'm new to this space but aren't these different asks / scenarios? The first is support for federated credentials on-behalf-of a user, the second seems more related to #27093 - just to make sure we have things tracked in the right place and partners can be informed of timelines

[MRayermannMSFT]

@maorleger I'm also new to the space of "federated credentials" so apologies if I stumbled upon the wrong issue. I agree that issue #27093 probably sounds like more of the right thing.

[bgavrilMS]

@chlowell @KarishmaGhiya - FIC is supported by 3p.

There are 2 types of FIC:

• with an external Identity Provider (e.g. GitHub). This allows a GitHub action to get access to KeyVault. See https://github.com/Azure/azure-workload-identity/tree/main/examples for examples for AKV, including with Azure SDK JS
• with Managed Identity. You get an S2S token from MSI - leg1. And use this token as the client_assertion in the OBO flow (or any other confidential client flow) - leg2.

From MSAL perspective this is very simple - all MSALs allow for specifying a client assertion. Just note that most samples (including https://github.com/Azure/azure-workload-identity/tree/main/examples) are wrong, because you have to ensure the token from leg1 is valid when you pass it to leg2. So you need to cache tokens from leg1 and from leg2.

@Robbie-Microsoft will be looking into the sample https://github.com/Azure/azure-workload-identity/tree/main/examples to fix it.

Hope this helps.

[KarishmaGhiya]

Chatted with @bgavrilMS
Assuming we add support for client assertion in OBO, the user can probably do something like this -

managedIdentity = new ManagedIdentityCredential()

getAssertion()=>{
msiAccessToken = await managedIdentity.getToken(<scope>)
return msiAccessToken;
}

oboCredential = new OnBehalfOfCredential(<tenantId>,<clientId>,getAssertion,<userAssertionToken>)

await oboCredential.getToken(<scope>)

[KarishmaGhiya]

Related MSAL feature issue for requesting Client Assertion callback input instead of a string - AzureAD/microsoft-authentication-library-for-js#7013