Why does daemon app require user sign-in in API service principal?

Question

I am following the code sample here:

https://github.com/Azure-Samples/active-directory-dotnetcore-daemon-v2/tree/master/2-Call-OwnApi#register-the-client-app-daemon-console

I am not using the sample code API, instead I have a simple test API. Both API and daemon client is running locally in two instances of Visual Studio. I am not using any scope in the exposed API, instead I have one app role defined. This app role is granted permission in daemon app service principle, and defined in the controller as [Authorize(Roles = "MyAPI.Read.All")].

In order to get results from the API to the daemon console app, I have to define the default scope in daemon appsettings.json , and set Enabled for users to sign-in? to Yes in the service principal of the API web app.

If I enable user sign-in, I can call the API and get expected results. I can add a breakpoint in API code, inspect the token, and see that the token has all the expected claims, including the app role.

If I disable user sign-in in the service principle, I get

Microsoft.Identity.Client.MsalServiceException: 'AADSTS500014: The service principal for resource 'api://<API web app ID>' is disabled.

when I call the API from the local daemon console app.

1. Why do I have to enable user sign-in to get authorized?
2. Why do I need to enable the default scope in the daemon app appsettings.json

Answer 1

It seems like enabling user sign-in and setting the default scope in your daemon app's settings are necessary steps for successful authorization when calling your API. Disabling user sign-in leads to a service principal disablement error, indicating a disruption in the authentication flow. The default scope likely ensures proper negotiation of access tokens for authorization. Double-checking authentication configurations and consulting Azure documentation or community support could provide clarity on these requirements.