How Can We Help?
When an application uses Azure Active Directory for identity authentication to protect its API, specific tokens are required on each request for them to be accepted. In cases where the application is accessed via browser, these can be obtained via the usual redirect-to-login authentication flow.
This is not so easy in other cases, such as website host daemons or standalone devices, but there are several paths available for these instances, both involving authenticating against an Azure AD application with the required permissions for the target’s API.
One option is to authenticate using a client secret or certificate as proof. This approach does not require any external interaction but can only be used to authenticate for a single AD application.
Another is to request a proxy sign-on and be returned an intermediate token and a link, in what is known as Device Authentication. The link is then forwarded to a user via email, text, or other external channels, against which they authenticate themselves and authorize the token, and by extension, the daemon app. This approach requires external input via a user, but can authenticate as the user that logged in.
In the .Net Core framework, these request are encapsulated and most easily accessible via the Microsoft.IdentityModel.Clients.ActiveDirectory NuGet package.
For both approaches, information about the target application is needed. Its ApplicationId and the Id of the Active Directory it resides in are both required.
It is also recommended to create a separate Azure AD Application to act as the “client”, which can be granted only the permissions required by the daemon instead of inheriting the permissions granted to the target app. While it is possible to authenticate as the target app, it may also be rejected by Active Directory, depending on the target application’s configuration and your chosen approach.
To utilize the client credential authentication path, an Azure AD application that is configured as a “Web App/ API” application that has permissions for the target API must be used as the client.
The client flow uses the following steps, with code examples:
- Assemble a request using the Tenant Id, the target resource’s Id, and the “Web App/API” client’s Id. (1, 2)
- Acquire the resource token. (3)
- Use the returned token
To utilize the device authentication path, an Azure AD application that is configured as a “Native” application that has permissions for the target API must be utilized as the client.
The device flow uses the following steps, with code examples:
- Acquire a device code and link using the Tenant Id, the target resource’s Id, and the “Native” client’s Id. (1, 2)
- Send the link to a user via any available channel. (3)
- Poll the device callback URL using the device code until the user authenticates and a token is returned. (4)
- Use the returned token.
As an example, this console application is using the device flow. Steps 1 and 2 are completed without user input.
Step 3
Step 4
Comments are closed.