Implement Azure security
Identity, secrets, and access
The modern pattern: an app authenticates with a managed identity, gets a token from Microsoft Entra ID, and uses it to call Key Vault, Storage, or SQL. No secrets in code or app settings. System-assigned identity is tied to one resource's lifecycle; user-assigned identity is standalone and can be attached to many resources. Managed identities work only within the same tenant and cannot be used from on-premises.
App registration: client ID, tenant ID, redirect URI, and a credential (secret or, better, certificate or federated credential). Flows: authorization code with PKCE for user-facing apps (SPA, mobile, desktop); client credentials for daemons with no user. Delegated permissions (scopes) act as the signed-in user; application permissions (app roles) act as the app itself and generally need admin consent. MSAL handles token cache, silent acquisition, and refresh - never hand-roll token requests.
Key Vault stores secrets, keys, and certificates. Authorization is either vault access policies or Azure RBAC - pick one model per vault. Reference secrets from App Service or App Configuration with Key Vault references (@Microsoft.KeyVault(...)) so rotation is transparent.
Traps
Granting a managed identity access to resources in another tenant; mixing access policies and RBAC on one vault; using client credentials when a user context is required; assuming a normal user can consent to application permissions; storing secrets directly in app settings.
Worked example
A Function reads a secret. Enable the function app's system-assigned identity, assign it the Key Vault Secrets User role on the vault, then use new DefaultAzureCredential() with SecretClient. No secret ever appears in configuration.
Rule of thumb
Secret in code or config → managed identity plus a Key Vault reference.