This console app is very simple to demonstrate a couple of key ideas:
- Connecting to Dataverse using DefaultAzureCredential
- Adding setings from KeyVault
Implementing these two ideas can easily eliminate the possiblity of passwords or app secrets making their way into source control.
I use KeyVault to store any secrets, key, credentials, or anything else I do not want in source control. A big advantage of using KeyVault even during development is those values that should be kept secret never exist on my local machine, other than in memory temporarily.
This also opens the potential to use Managed Identities in Azure Functions, WebApps, etc... to connect to Dataverse.
The key to this functionality is the DefaultAzureCredential class. This class will look for a token using the following place in order:
- EnvironmentCredential
- WorkloadIdentityCredential
- ManagedIdentityCredential
- SharedTokenCacheCredential
- VisualStudioCredential
- VisualStudioCodeCredential
- AzureCliCredential
- AzurePowerShellCredential
- AzureDeveloperCliCredential
- InteractiveBrowserCredential
I have found the easiest method to using the DefaultAzureCredential within Visual Studio debugging sessions takes three steps:
Once the Azure CLI is installed it is two easy steps:
- In Visual Studio open Developer PowerShell terminal.
- Enter
az loginand press Enter. This will open a browser window where you login and the close the window/tab.
That is it. From then on in Visual Studio the DefaultAzureCredential will resolve to the credentials you entered. It is possible for it to pick up your Visual Studio credential but I ran into many times where the Visual Studio credential cache had timed out and didn't work. Using az login seems to work the best.
I can't take credit for the GetDataverseToken method that credit goes to Dreaming in CRM