This post has been republished via RSS; it originally appeared at: Azure Data Explorer articles.
While AAD user authentication is very easy (as users are defined in AAD by the tenant admin, such as MSIT in case of Microsoft), AAD application authentication is somewhat more complex, because it requires creating and registering the application with AAD. As this process is unfamiliar to many people, it is described here in some details.
AAD application authentication is useful for applications that need to access Kusto without a user being logged-on or present (e.g., an unattended service or a scheduled flow).
Client applications and middle-tier applications that have an interactive user context should avoid this model, as authorization is performed based on the AAD application identity instead of user identity, so the calling application will need to implement its own authorization logic to prevent misuse.
Application Authentication use cases
We can distinguish two main scenarios that make use of application authentication:
- Applications that are intended to contact the Kusto service directly and on their own behalf
- Applications that will authenticate their users to Kusto (delegated authentication)
- Provisioning a new application
- Set permissions to the application on Kusto cluster
- Application can now access Kusto
Learn more on HowTo Create an AAD Application using Azure Data Explorer on Azure Data Explorer access control.
“Join the conversation on the Azure Data Explorer community”.