*Credential.getToken support for clientID and tenantId

In C# if you are still using AzureServiceTokenProvider.GetAccessTokenAsync(…) and pass in a resource (clientID) and a tenantID, it allows you to directly call the Azure application. I do not see an equivalent case in @azure/identity.

var clientId = "{GUID}";
var tenantID = "{GUID}";
var identity = "RunAs=App";
 
var azureServiceTokenProvider = new AzureServiceTokenProvider(identity);
var accessToken = azureServiceTokenProvider.GetAccessTokenAsync(clientId, tenantID).GetAwaiter().GetResult();
Console.WriteLine(accessToken);

The scenario is we are using a system managed identity for an Azure Function and trying to get a token from an OAuth2 endpoint that represents APIM.

[normand-MSFT]

Passing in the clientid of the app worked. The confusing part and why we didn’t look at that before, even though from your perspective the user assigned MSI and app registration clientID are the same, is the documentation. That implies we need to create a standalone managed identity azure resource. We just needed to also use a scope of “api://{guid}/.default” though (a different issue) why we are limited to using .default.

The client id to authenticate for a user assigned managed identity. More information on user assigned managed identities can be found here: https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview#how-a-user-assigned-managed-identity-works-with-an-azure-vm

[ramya-rao-a]

Thanks for sharing the C# code snippet that you are trying to convert

I looked into the implementation of AzureServiceTokenProvider and it looks like it uses the “connectionString” passed to the constructor to determine how to do authentication. The “connectionString” is a list of key value pair and when you pass “RunAs=App”, it uses the Managed Identity.

This way of using connection string like input to determine behavior is not encouraged anymore due to the nature of it being prone to human error when the string is being constructed. I am not aware of what the counterpart for this is in the newer .NET libraries, but we can share the recommended practice in JavaScript/TypeScript.

RunAs=App should translate to the system managed identity for the Azure Function. Its equivalent should be ManagedIdentityCredential without parameters.

You are right in determining that using the ManagedIdentityCredential without parameters as the path forward. You can then await on the getToken() call on the credential to get your token. Can you share what issues/errors you found when doing so?