[QUERY] How to test local app using 'DefaultAzureCredential' to call a custom API?

Library name and version

Azure.Identity 1.5.0

Query/Question

I have a durable function that performs an authenticated DELETE call using DurableHttpRequest to a protected API hosted in AppServices. I’m getting a 403 response in the cloud environment even after I’ve already added the required app-role to the function’s system-assigned managed identity using Powershell.

When trying to run this same function locally, I get a failure message during the token retrieval phase stating that I need to give consent for Visual Studio to access my application:

Error, TS004: Unable to get access token. 'AADSTS65001: The user or administrator has not consented to use the application with ID ‘872cd9fa-d31f-45e0-9eab-6e460a02d1f1’ named ‘Visual Studio’. Send an interactive authorization request for this user and resource.

I tried manually calling the admin consent URL with this API and my resource: https://login.microsoftonline.com/{my_tenant_id}/adminconsent?client_id=872cd9fa-d31f-45e0-9eab-6e460a02d1f1&scope=api://{my_api_id}/.default

This results in a dialog asking me if I’m trying to sign in to Visual Studio:

Clicking on continue results in a redirection to https://login.microsoftonline.com/appverify?... with a blank page.

If I then try again to call my API while debugging the durable function, the exact same error occurs.

After investigating what the code in the durable functions extensions does, I created a sample console application that reproduces the exact same issue with just a few lines of code:

using Azure.Core;
using Azure.Identity;

Console.WriteLine("Hello, World!");

const string myApiClientId = ....
var credential = new DefaultAzureCredential();
var context = new TokenRequestContext(scopes: new[] { $"api://{myApiClientId}/.default" });
var result = await credential.GetTokenAsync(context);

Using this code, I get the exact same error as what happens inside the function app locally. I made sure to add Azure.Identity v1.5.0 which is the same version being used by my function app through Microsoft.Azure.WebJobs.Extensions.DurableTask v2.7.0.

I feel like I’m missing something fundamental here, but every sample I find of Durable Functions calling into protected APIs using DurableHttpRequest are calling other Azure APIs, like management, instead of calling a custom one. I assume Visual Studio has built-in permissions for those (or something?).

I also don’t quite understand why I can’t find any hint of a “Visual Studio” app registration in the portal anywhere: if I search either by text or by the ID 872cd9fa-d31f-45e0-9eab-6e460a02d1f1, nothing comes up.

Could someone help me in how to get this working from local debugging? Is it even possible? Do I need to “give permissions to Visual Studio to access my API?” If so, how do I even do that considering I can’t even find the “Visual Studio” app anywhere?

I also considered making a manual authorize/token call while “impersonating” the function’s managed identity to double/triple check the token being returned, but I don’t know how to do that either… I’m sure the token has something in it, since prior to giving the function permissions, I got an exception in the API due to “lack of scopes and roles” in the JWT: now this has changed to a 403 which signals that “there should be a role in there” but it is somehow wrong. Durable functions itself doesn’t persist the token used anywhere (which I imagine is done on purpose for security reasons) but then I can’t also inspect the token from there. Similarly, logs in Application Insights for AspNetCore don’t include any headers so I can see the token that is arriving in the API…

I’ve spend several hours trying to make this work today and I feel I haven’t progressed much if at all 😢 Any help will be hugely appreciated.

Environment

AppService, Windows 10, NET6 Visual Studio 17.1.4

[kacperwojtyniak]

I have run against the same issues. I am trying to get a token for my custom App Registration and receive the following error:

Azure.Identity.CredentialUnavailableException : DefaultAzureCredential failed to retrieve a token from the included credentials. See the troubleshooting guide for more information. https://aka.ms/azsdk/net/identity/defaultazurecredential/troubleshoot
- EnvironmentCredential authentication unavailable. Environment variables are not fully configured. See the troubleshooting guide for more information. https://aka.ms/azsdk/net/identity/environmentcredential/troubleshoot
- ManagedIdentityCredential authentication unavailable. Multiple attempts failed to obtain a token from the managed identity endpoint.
- Process "C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\CommonExtensions\Microsoft\Asal\TokenService\Microsoft.Asal.TokenService.exe" has failed with unexpected error: TS003: Error, TS004: Unable to get access token.  'AADSTS65001: The user or administrator has not consented to use the application with ID '04f0c124-f2bc-4f59-8241-bf6df9866bbd' named 'VS with native MSA'. Send an interactive authorization request for this user and resource.

My code looks like this:

var tokenCredential = new DefaultAzureCredential();
var accessToken = await tokenCredential.GetTokenAsync(new TokenRequestContext("api://guid/.default"));

I am using Azure.Identity package in version 1.7.0.

I was able to resolve the issue by going to my App Registration and in Expose an API add the GUID printed out in the error message, i.e. “04f0c124-f2bc-4f59-8241-bf6df9866bbd”.

I cannot find any documentation about this. What this GUID represents, where to find it?

[julealgon]

I’m confused @christothes . If I need to change the credential I’m using to debug locally, then that would end up impacting my real application as well. I’m using DefaultAzureCredential precisely because I want it to be resolved automatically when actually running the function in AppService.

Are you saying now that I need to have branching code in my project to be able to test this? “if development => EnvironmentCredential, else DefaultAzureCredential”? If that’s the case, that makes the local debugging experience vastly worse.

My understanding was that it should be possible to add the necessary permissions to the built-in applications instead (Visual Studio, CLI, etc) like this post mentioned. That approach felt to me like a workaround though so I was still waiting for official confirmation on it.

What you are suggesting now is completely different however and would force code changes either permanently (to allow my whole team to seamlessly debug the function) to the codebase.