Information technology tools and resources at the UW
Azure AD Application Credentials
When you provision an Azure AD application which you are developing, you must have two things: a client id and a credential to prove you are the application.
You will need to decide on one of two options:
- A shared secret (passwordCredentials)
- Public/private key signing (keyCredentials)
Both have expirations so there is a lifecycle built into all AAD apps, such that you must do something to keep things running indefinitely. We provisioned an Azure AD application for a customer, and a year later learned a little lesson when that credential expired without being on anyone’s radar to renew it. We can work with customers through the details around ensuring you can manage the credential lifecycle, but you will need to pick one of the above two credential options.
A simple choice is the passwordCredentials method. With that, you can do 1y or 2y periods. Because we don’t allow users to create AAD apps (currently), a developer can’t use the nice features built into Visual Studio to get these credentials (but documentation may tell you that you can do this). This leaves the Azure management portal. Once you “generate” the shared secret, you must copy the auto-generated value from the portal, because once you leave that portal page, it is not saved anywhere you can access. Your code then supplies that shared secret along with client id to authenticate your app.
The keyCredentials method is based on your app possessing the private key for a cert and provisioning the public cert in Azure AD on the app. This has some obvious advantages from a couple perspectives, but based on information in Vittorio Bertocci’s book, I believe you can only use PS to provision this. That said, it might be a better option as it’d mean access to your source code (and the embedded secret) does not mean access to whatever resources your application can get access to, and you can use a cert with an expiration longer than 2 years.