Secretless Service Access with UAMI Federation

If I had to pick the part I hate most about SPN-based integrations, it would be the secret. Rotation is consistently problematic: applications pick up the wrong version, keep using a cached old one, or force service owners into a lifecycle that is either too short or too long. Better to skip it entirely.
If you want an Azure-hosted workload to access a downstream API without storing a client secret, a cleaner pattern is to avoid giving those application permissions directly to the UAMI.

Instead, split the roles.

• the User-Assigned Managed Identity (UAMI) is the Azure-side runtime identity,
• the Entra App Registration and its Service Principal are the downstream application identity,
• the federated credential creates the trust between them.

Your Azure workload runs with a UAMI, but the actual API permissions belong to a separate app registration. That keeps the setup secretless, because there is no client secret or certificate in the integration.

How the pattern works

At runtime, the Azure-hosted workload uses the attached UAMI as its authentication carrier.

It does not call the downstream API on the UAMI’s own permissions. Instead, Entra accepts the UAMI as a trusted federated identity for a specific app registration and issues a token for that app.

That means the UAMI stays the Azure runtime identity, while the app registration stays the permission container.

The UAMI is not the permission container. The application permissions live on the Entra application.

The federation details

The trust is configured on the Entra App Registration under Federated credentials.

The key values are:

• issuer: the tenant v2 token issuer URL,
• Value: the UAMI principalId,
• audience: api://AzureADTokenExchange.

With that in place, Entra can issue an application token for the app registration when the workload runs under the trusted UAMI.

The critical difference is this:

• the required application permissions are granted to the app registration,
• the federated credential is only a trust relationship,
• the workload uses that trust chain when it connects to the downstream API.

What the Azure workload needs

On the Azure side, the important pieces are:

• the workload with the user-assigned managed identity attached,
• the target integration or connector,
• the application configuration that tells it which app registration to use.

The configuration usually references:

• the app ApplicationId in the connection settings,
• optionally the TenantId,
• the UAMI in the identity settings.

The important part is that the workload points to the UAMI identity instead of storing a secret.

The exact application settings depend on the service, but the identity pattern stays the same.

Permission models

There are two realistic permission models.

• broad application permissions for the downstream API,
• or narrowly scoped application permissions where the platform supports them.

The broader model is easier to validate quickly. The narrower model is the better long-term option if you want least privilege.

Why this pattern is better

The big win here is not only that it is secretless. It is also cleaner operationally.

• Cleaner security boundary

  The UAMI is the Azure workload identity. The app registration is the downstream authorization boundary.

• Better auditability

  It is easier to see which app has access to the downstream system, because the permissions live on a dedicated Entra application.

• More stable lifecycle

  If you replace the UAMI, the app registration and downstream grants can stay as they are.

• Better governance

  Runtime identity and application permissions are easier to manage when they are separated.

• Least-privilege friendly

  It works well when the target platform supports scoped application access.

• Simply better for production

  It is easier to audit and maintain than putting a client secret into the integration.

Final thoughts

An Azure-hosted workload can use a UAMI as the runtime identity, a separate Entra application can carry the downstream API permissions, and a federated credential connects the two.

That is usually a cleaner and more supportable model than storing application credentials in configuration.