Today, we’re announcing the Public Preview of Managed Identities as Federated Identity Credentials for Microsoft Entra. Securely access Entra-protected resources like Microsoft Azure, Microsoft Graph, and third-party APIs using a managed identity instead of a secret or certificate.
Key benefits:
- Improved security: Eliminating the use of secrets and certificates in app authentication reduces the risk of credential leaks.
- Simplified setup: Using a managed identity as a federated identity credential (FIC) provides continuous access to resources without the need to manage secret and certificate expiration and renewal.
How it works
In addition to client secrets and certificates, apps today can use Federated Identity Credentials (FICs) to accept access tokens from trusted identity providers. This process, known as the Workload Identity Federation flow, supports tokens from GitHub, Kubernetes, and other third-party OIDC issuers. With this new capability, apps can also accept managed identity tokens issued by Microsoft Entra.
Once configured, an app can exchange the managed identity token ((a) in the diagram) for an access token to access Microsoft Entra-protected resources ((b)), eliminating the need to manage app secrets or certificates.
Getting started
To begin, assign a user-assigned managed identity to the Azure resource (for example, VM, App Service) that is hosting your workload.
Next, you need to make your app trust the managed identity.
Navigate to your app registration in the Entra Portal or Azure Portal:
- Go to Certificates & secrets.
- Select the Federated credentials tab.
- Click Add credential to begin configuring the federated identity credential.
In the Federated Credential form:
- Set the Scenario to ‘Other’.
- For Issuer, enter the OIDC issuer URL of your tenant (for example, ‘https://login.microsoftonline.com/{tenantId}/v2.0’).
- Set the Subject as the Object (Principal) ID of your Managed Identity.
You can find the Object ID on the Overview page of the managed identity in the Azure Portal.
Token exchange and resource access through code
To obtain the app’s access token in your code, follow a two-step process:
- Get the managed identity token.
- Use the token as a client assertion to retrieve the access token.
Below is an example in C# for accessing an Azure Storage account using the Azure Identity library:
static public async Task ListBlobs()
{
// Storage account and container details
string accountName = "your_storage_account_name";
string containerName = "your_container_name";
// Entra ID (aka Azure AD) details
string tenantId = "the_tenant_id_of_the_storage_account"; // Where the resource exists. I.e, the tenant of the storage account.
string appClientId = "your_app_client_id"; // the client id of the app registration that has access to the storage account.
string managedIdentityClientId = "your_managed_identity_client_id"; // which was specified in the App's Federated Identity Credential
string audience = "api://AzureADTokenExchange"; // Must set audience to this value in public cloud workloads.
// Get the managed identity credential
var managedIdentityCredential = new ManagedIdentityCredential(managedIdentityClientId);
// Create a Client Assertion containing the Managed Identity access token
ClientAssertionCredential assertion = new(
tenantId,
appClientId,
async (token) =>
{
// fetch Managed Identity token for the specified audience
var tokenRequestContext = new Azure.Core.TokenRequestContext(new[] { $"{audience}/.default" });
var accessToken = await managedIdentityCredential.GetTokenAsync(tokenRequestContext).ConfigureAwait(false);
return accessToken.Token;
});
// Sending the assertion to the BlobContainerClient authenticates using the Federated Credential
BlobContainerClient containerClient = new BlobContainerClient(
new Uri($"https://{accountName}.blob.core.windows.net/{containerName}"),
assertion);
// List all blobs in the container
await foreach (var blob in containerClient.GetBlobsAsync())
{
Console.WriteLine(containerClient.GetBlobClient(blob.Name).Uri);
}
}
Multi-tenant usage
To access resources in other tenants, use the same FIC configuration and ensure your App Registration is Multitenant. This allows admins of the remote resource tenant to add and provision your app into their tenant.
For more details about app provisioning, see How and why applications are added to Microsoft Entra ID.
Creating Managed Identity FICs on apps using Bicep
Automating the provisioning of a federated identity credential is fully supported using Bicep. Below is an example of deploying an FIC using Bicep:
extension microsoftGraph
resource myApp 'Microsoft.Graph/applications@v1.0' = {
displayName: applicationDisplayName
uniqueName: applicationName
resource myMsiFic 'federatedIdentityCredentials@v1.0' = {
name: 'myAppName/msiAsFic'
description: 'Trust the workload\'s user-assigned MI as a credential for the app'
audiences: [
audiences[cloudEnvironment].uri
]
issuer: '${environment().authentication.loginEndpoint}${tenant().tenantId}/v2.0'
subject: '[YOUR-MANAGED-IDENTITY-PrincipalId]'
}
}
Next steps and recommendations
Customers using Microsoft Entra ID applications to authenticate users, access resources on behalf of users, or perform cross-tenant access can enhance their security by adopting managed identities as federated identity credentials. This approach is more secure and robust compared to managing secrets, rotating certificates, and handling multiple permission sets for apps and managed identities.
To further explore this feature, please visit the official public preview documentation.
Stay connected and informed
To learn more or test out features in the Microsoft Entra portfolio, visit our new developer center. Make sure you subscribe to the Identity blog for more insights and to keep up with the latest on all things Identity. And, follow us on YouTube for video overviews, tutorials, and deep dives. 
This is cool. I will call this feature FIC. Now to audit all apps and reevaluate app design. Replace any replaceable and reintegrate into pipelines. I like it. Thank you MIcrosoft.
Yes, finally! This closes a huge (and frankly a bit ridiculous) gap we’ve bridged on other platforms already (e.g. GitHub and ADO).
Can we expect this to be supported by the “native” authentication features for app services, function apps and static web apps in the near future as well?
Wow! I’ve been wanting something like this for years. Our bold secret-less future is getting closer!
I hope work is ongoing in Azure.Identity to reduce the amount of code required, similar to the Microsoft.Identity.Web.