So you ask what is native application? In the Azure AD speak, a native application (sometimes also referred to as native client) is an application that runs on a device (phone, tablet, PC etc.) and needs to authenticate a user to get resources from a web API that is secured by Azure AD. In the context of Key Vault, this would be an application that you want to write, which will access Key Vault by acquiring a token from Azure AD, using a user’s credential. Compare that to a service or web application that uses client ID and a secret (or a X509 certificate) to acquire token from Azure AD. The difference being use of user credentials versus client ID and secret or a certificate.
Now you’ll ask, aren’t Azure PowerShell and Azure Cross-platform Command Line Interface examples of such native clients? Yes they are, but they worked without this feature, as they were well known apps that were grandfathered in. Now you can write your own native client applications to access Key Vault. Native client application needs to be configured differently from the web apps or headless worker role etc. So read on!
Note: Native application support for Key Vault is available in all public Azure regions. Soon it will also be available in Azure Government, Azure China and Azure Germany.
Say you want to develop your own client application so that users can use their own credentials and access key vault. This could be for retrieving a secret from Key Vault that the application uses, or accessing a key for some cryptographic operations.
Registering native client application with Azure Active Directory
Go to Azure Portal and login to your subscription. Then click on ‘More Services’ and scroll down the list to find Azure Active Directory (preview) and click on it.
Now click on ‘App Registrations’ and then click ‘Add’ at the top.
Enter name for your application, and select ‘Application Type’ as ‘Native’. Enter a valid redirect URI, don’t worry about this value. It only needs to be a valid URI, it doesn’t have to actually exist. Then click create.
Now you will see your newly created application listed in the ‘App registrations’ blade. But we are not done yet. There are a few more settings to take care of. So click on your new application and then click on the ‘Required permissions’ under the ‘API ACCESS’ section in the ‘Settings’ blade.
Now click on ‘Add’ in the ‘Required permissions’ blade. Click on Select an API, type ‘AzureKeyVault’ (no spaces) in the search box then click ‘Azure Key Vault (AzureKeyVault)’ and then click Select.
Then in ‘Select permissions’ blade check ‘Have full access to the Azure Key Vault service’ then click ‘Select’ and then ‘Done’ in the Add API Access blade.
Note: If you have not created a new Key Vault in recent months, you may not see the ‘Azure Key Vault (AzureKeyVault)’ listed as shown. If you encounter such scenario, simply create a new key vault in your subscription, and return to this step. Creation of a new key vault will trigger registration of Azure Key Vault service in your tenant and then it will show up in the list as shown.
Note down the Application ID and Redirect URI of your application. You’ll use it in your code.
For a native client you will not use a client ID and client secret (or a X509 cert) like a Web App or API type application does. Notice there is no use of clientCredential in the native application. You’ll need to get client ID (referred to as Application ID above) and Redirect URI from the app.config. In addition, PlatformParameters will invoke user authentication dialog.
/// Get clientID and clientRedirectURI from app.config var clientId = ConfigurationManager.AppSettings["AuthClientId"]; var clientRedirectURI = ConfigurationManager.AppSettings["AuthClientRedirectURI"]; : : /// Get AAD token var context = new AuthenticationContext(authority, TokenCache.DefaultShared); var result = await context.AcquireTokenAsync(resource, new Uri(clientRedirectURI), new PlatformParameters(PromptBehavior.Always)); return result.AccessToken;
When you run your native client application, it will automatically prompt user to enter Azure AD credentials. If your directory administrator has configured multi-factor authentication, user will also be presented related prompts. To successfully access keys/secrets in the key vault, the user must have specific permissions to perform those operations. This could be achieved by directly adding an access policy entry for this user or an access policy entry for a Azure AD security group which this user is a member of.
So there you have it! You can now write your own key vault application where user credentials are used to access a key vault.