I am not sure whether the
access_token that you have received from Azure Authentication has permanent lifetime. I am assuming it is not. Either way, you still need to have
client_secret to get the
access_token, and that means you should instead focus on securing the
client_secret or finding the alternatives.
Instead of using
client_secret to authenticate, you can use client certificate authentication as explained in this documentation: Authenticate with a Certificate instead of a Client Secret.
In the picture above, the developer does not need to know the private key value of the certificate in order for their app to be successfully authenticated to Azure Active Directory. Instead, they only need to know the location of the imported
pfx in the Certificate Store.
At least on Windows, you as secret administrator can convert the private key and the certificate into
pfx format which is password protected, and then deploy it into the Windows Certificate store. This way no one could know the private key unless they know the password of the
The other approach specifics for Azure Compute, is to use Azure Managed Service Identity. Using Azure MSI, Azure will automatically assign your resources such as VM with an identity / Service Principal, and you can fire requests at a specific endpoint that are only accessible by your resource to get the
access_token. But be wary that Azure MSI are still under public preview, so please review the known issues before using it.
The picture above explain how Azure Resource Manager assign a Service Principal identity to your VM.
- When you enable MSI in a VM, Azure will create a service principal in your AAD.
- Azure will then deploy a new MSI VM extension to your VM. This provides an endpoint at http://localhost:50432/oauth2/token to be used to get the
access_token for the service principal.
- You can then use the
access_token to access the resources such as Key Vault which authorize the service principal access.