skip to Main Content

I am adapting the project sample provided by Microsoft for Multi-tenant Azure AD apps.

I am extending SurveyAuthenticationEvents.TokenValidated() so that in the sign up logic, I hit up Microsoft Graph to get the tenant display name so we can store something a little more meaningful than just a GUID to identify the new tenant.

Something like this:

Organization? org = default;
var tokenAcquisition = context.HttpContext.RequestServices.GetRequiredService<ITokenAcquisition>();
var auth = await tokenAcquisition.GetAuthenticationResultForUserAsync(new string[] { "User.Read" }, tenantId: azureTenantId, user: context.Principal); // "User.Read", "Organization.Read.All"
var graphClient = new GraphServiceClient(
    new DelegateAuthenticationProvider(
        (requestMessage) =>
        {
            requestMessage.Headers.Authorization = new AuthenticationHeaderValue("bearer", auth.AccessToken); // context.SecurityToken.RawData);
            return Task.CompletedTask;
        }));
var results = await graphClient.Organization.Request().Select(x =>x.DisplayName).GetAsync();
org = results.FirstOrDefault();

The third line is failing with the exception:

Microsoft.Identity.Client.MsalUiRequiredException: AADSTS65001: The user or administrator has not consented to use the application with ID ‘xxxxxx’ named ‘xxxxx’. Send an interactive authorization request for this user and resource.

Please note that this is IMMEDIATELY after the tenant administrator has just consented.

However, the error seems to be intermittent. In fact if I debug and break on the problematic line, wait a couple of seconds and then let it run it works fine. It is as if Azure AD needs a second or two after the consent to properly update the service principals and consent status for the new tenant, before it will issue an access token for a downstream API.

Am I missing something here or do I just add some retries and work around the issue?

2

Answers


  1. Chosen as BEST ANSWER

    Based on some feedback on github (https://github.com/mspnp/multitenant-saas-guidance/issues/127) it appears that the issue is indeed due to timing issues with AzureAD infrastructure, possibly related to caching.

    Would be fantastic if this was documented!

    I have now introduced some retry logic that simply waits a few seconds and retries the same request (up to 5 times) and the sign up logic now works as expected.

    Thanks to @dmcsweeney on github


  2. If an admin consent is already believed to be done , maybe all of the required permissions listed in the sign-in request were not consented to

    or

    the wrong application was used based on the App-Id}from the table above.
    In that case try to add this as an authorized client application
    enter image description here

    Once the application has been consented ,please make sure the prompt parameter is not being specified. If prompt parameter is still passed after consent this error might occur

    For workaround delete the package , permissions and again add it so your permission request gets created again.Also check if you need additional permissions like openid , profile ,offline_access for refresh token in your case.

    Please check other possible causes here
    Troubleshooting consent in Azure AD | Azure Active Directory Developer Support Team (aaddevsup.xyz) which can guide to troubleshoot

    Reference:

    Unexpected consent prompt when signing in to an application – Microsoft Entra | Microsoft Docs

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search