A user security principal identifies an individual who has a profile in Azure Active Directory.

A group security principal identifies a set of users created in Azure Active Directory. Any roles or permissions assigned to the group are granted to all of the users within the group.

A service principal is a type of security principal that identifies an application or service, which is to say, a piece of code rather than a user or group. A service principal's object ID acts like its username; the service principal's client secret acts like its password.

For applications, there are two ways to obtain a service principal:

Recommended: enable a system-assigned managed identity for the application.

With managed identity, Azure internally manages the application's service principal and automatically authenticates the application with other Azure services. Managed identity is available for applications deployed to a variety of services.

For more information, see the Managed identity overview . Also see Azure services that support managed identity , which links to articles that describe how to enable managed identity for specific services (such as App Service, Azure Functions, Virtual Machines, etc.).

If you cannot use managed identity, you instead register the application with your Azure AD tenant, as described on Quickstart: Register an application with the Azure identity platform . Registration also creates a second application object that identifies the app across all tenants.

Configure the Key Vault firewall

By default, Key Vault allows access to resources through public IP addresses. For greater security, you can also restrict access to specific IP ranges, service endpoints, virtual networks, or private endpoints.

For more information, see Access Azure Key Vault behind a firewall .

The Key Vault request operation flow with authentication

Key Vault authentication occurs as part of every request operation on Key Vault. Once token is retrieved, it can be reused for subsequent calls. Authentication flow example:

A token requests to authenticate with Azure AD, for example:

If authentication with Azure AD is successful, the security principal is granted an OAuth token.

A call to the Key Vault REST API through the Key Vault's endpoint (URI).

Key Vault Firewall checks the following criteria. If any criterion is met, the call is allowed. Otherwise the call is blocked and a forbidden response is returned.

If the firewall allows the call, Key Vault calls Azure AD to validate the security principal’s access token.

Key Vault checks if the security principal has the necessary permission for requested operation. If not, Key Vault returns a forbidden response.

Key Vault carries out the requested operation and returns the result.

The following diagram illustrates the process for an application calling a Key Vault "Get Secret" API:

Key Vault SDK clients for secrets, certificates, and keys make an additional call to Key Vault without access token, which results in 401 response to retrieve tenant information. For more information see Authentication, requests and responses

Authentication to Key Vault in application code

Key Vault SDK is using Azure Identity client library, which allows seamless authentication to Key Vault across environments with same code

Azure Identity client libraries

More information about best practices and developer examples, see Authenticate to Key Vault in code

Next Steps

Key Vault developer's guide

Assign a Key Vault access policy using the Azure portal

Assign Azure RBAC role to Key Vault

Key Vault access policy troubleshooting

Key Vault REST API error codes

What is Azure role-based access control (Azure RBAC)?