Azure managed identities: connect applications without storing client secrets

Replace a stored secret with a deployment identity

Managed identities let supported Azure resources request Microsoft Entra tokens without keeping an application client secret in their settings. Azure manages the identity's credentials. The application still needs to obtain a token for the target service and present it correctly. Enabling an identity is therefore one part of the integration, not a complete access grant.

A typical flow is straightforward: the application selects its managed identity, requests a service token through a supported Azure Identity credential, and calls the service endpoint. The service then evaluates that identity's permissions. This separates credential handling from authorization and makes it possible to investigate each boundary independently.

Choose the identity lifecycle deliberately

A system-assigned identity belongs to one Azure resource and follows that resource's lifecycle. Deleting the resource removes its associated identity. This is a good fit when the deployment and the permission subject should be retired together. It also means recreating a resource can require new role assignments because the replacement identity is a different principal.

A user-assigned identity is a separate Azure resource that can be attached to supported workloads. Its lifecycle can outlast an individual application instance. That is useful for controlled replacements or several resources with the same access requirement, but sharing an identity broadens the set of workloads able to use its grants. Separate identities when workloads have different trust boundaries.

Grant service permissions after enabling the identity

1. Enable the chosen identity on the hosting resource.
2. Record the principal object ID and, for a user-assigned identity, the client ID used for selection.
3. Assign the required service role at the narrowest supported scope.
4. Configure the application's credential chain to select the intended identity.
5. Run a real service operation from that host and confirm an unrelated operation stays denied.

Use object IDs for permission assignments and the identity selector expected by the SDK for credential selection. These identifiers have different purposes. Copying an application client ID into an object-ID field is a common source of confusing grants. Keep the identifiers in deployment outputs with clear labels so the distinction survives an operational handover.

Check what changes between local and hosted execution

A development credential chain might use the signed-in developer locally and managed identity after deployment. Those principals can have different permissions. A local success does not prove the hosted identity is configured correctly. Log a safe environment label and the credential mechanism being used, then verify the operation from the actual deployment.

Managed identity does not open a firewall, repair DNS or bypass service-level authorization. For a private endpoint, test name resolution and reachability from the application's network before interpreting an access failure. For an HTTP 403, inspect the target role and scope. For a token-acquisition failure, inspect identity attachment and credential selection.

Retire access as well as resources

When a workload is removed, review its role assignments and any separately managed identity. A surviving user-assigned identity might still hold access to storage, a vault or a registry. Treat it as an owned resource with a purpose and retention decision. Managed identities reduce secret rotation work, while clear ownership and scoped permissions keep the resulting system understandable.

References

• Managed identities for Azure resources - Managed identities — Microsoft Learn
• What is Azure role-based access control (Azure RBAC)? — Microsoft Learn