This article looks at Azure Active directory and consent with multi-tenant Azure App registrations. Consent works different depending on the user type, the tenant policies and the required permissions. It is sometimes hard to understand why a user cannot login or where the consent has to be given for a specific Azure App registration which exposes permissions or business functions.

Code: https://github.com/damienbod/AspNetCoreTenantSelect

Setup

An Azure App registration was setup as a Web client using a secret which uses some basic delegated permissions. The Azure App registration is a multi-tenant application. You can verify that the Azure App registration is a multi-tenant one by opening the manifest file and checking the signInAudience property.

"signInAudience": "AzureADandPersonalMicrosoftAccount",

You can also check this directly in the portal using the authentication blade.

When using a delegated multi-tenant Azure App registration you do NOT give consent using the Azure App registration. You give consent to a user or an administrator using the Enterprise application created for your tenant for the Azure App registration. Each multi-tenant Azure App registration can have multiple Enterprise applications each which would require consent depending on the user type, the tenant policies and the permissions required.

An ASP.NET Core application was implemented to authenticate using Azure AD and because it’s a multi-tenant application, any Azure AD user from any tenant could authenticate using the application. When using multi-tenant applications, you need to restrict the access by validating the acr claims, the user and other such authorization checks.

Microsoft.Identity.Web is used to implement the ASP.NET Core authentication. This hides and renames the OpenID Connect standards which are used. These packages are optimized for ASP.NET Core and uses MSAL.

services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd"));

The Micorosoft.Identity.Web package uses the AzureAd configuration per default which can be renamed if required. The TenantId is set to common for the multi-tenant access.

  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "Domain": "damienbodhotmail.onmicrosoft.com",
    // Use common for multi tenant applications
    "TenantId": "common",
    "ClientId": "086233fd-a846-47e0-a057-7aa05b5a5479", 
    "CallbackPath": "/signin-oidc",
    "SignedOutCallbackPath ": "/SignoutCallbackOidc"
    // "ClientSecret": "add secret to the user secrets"
  },

Grant consent as an admin

When you authenticate from the application for the first time as an Azure administrator user, a consent screen which allows you to Consent of behalf of your organization is displayed. If you check the checkbox, all users and administrators can use the application. If you do not check this checkbox and you give only your consent, only you can use the application and other administrator users can give consent as well. No Azure AD user can access with this consent.

Grant consent as a user

When an Azure AD user uses the application (not an administrator) and no admin consent has already been set for the tenant, the consent screen, is displayed for the user if only not admin delegated permissions are required and the tenant policy allows this. A user could then give a user consent for this account.

Normally the user requires an administrator to give admin consent for all user before a user of a specific tenant can access the application.

Enterprise application

If an administrator has already given a user consent for their own account, an Azure Enterprise application is created inside the tenant. You can view all the user consents already given in the permissions blade.

Grant consent for the whole tenant using the portal

You could give consent for all users using this application. This would be required if no consent has been given for all users but the IT admin has already consented for a single account.

Remove consent using the Enterprise application

It is really important to remove consent if no longer used. This can be done in the Enterprise application created from the Azure App registration for the specific tenant. This can be done in the properties blade.

Consent can be hard to setup on a specific tenant because this depends on different setups. The account type, the Azure AD policies and the required permissions all change how the consent is displayed, blocked or can be given. You should also verify the tenant where the multi-tenant Azure App registration is implemented.

Powershell commands

Connect-AzureAD -TenantId '<YourTargetTenant>'                                            

New-AzureADServicePrincipal -AppId '<objectId>'

Give Consent in your tenant to the Enterprise applications

1. Open the Enterprise Applications blade
2. Find your enterprise application using the guid AppID
3. Open the permissions blade
4. Grant Admin consent

Links:

https://learn.microsoft.com/en-us/azure/active-directory/develop/application-consent-experience

https://learn.microsoft.com/en-us/azure/active-directory/develop/publisher-verification-overview