Have you ever trying to find user consent from Azure AD for an application which is using V2.0 Azure AD endpoint and dynamic permissions? For background information About V2.0.

I this particular scenario Power BI Content Pack is added to Azure AD. It was added with Global Admin account who made admin and user consent.

As seen below everything seems normal, consents are in place and visible from Azure AD portal.

BI-1

BI-2.PNG

When another user who doesn’t have permissions to Azure AD tries to add content pack admin interaction is needed for consent.

1.PNG

After the consent, the user is able to fetch the data, excellent. Everything works as expected.

power-bi.PNG

But, what if customers ask you to remove the permissions? The answer is remove consent, the question is where is it located?

The user doesn’t have permissions to any application

Jd-3.PNG

Azure Audit log shows only the consent I did in the with my GA account when adding content pack

consent.PNG

Fiddler trace shows interesting permissions when Global Admin adds consent to another user

offline_access

I tried to search consent with multiple tools and the closest one was O365 Audit logs where I could find that specific user created Power BI dashboard and dataset.

O365-Audit

From another user

create-dashboard.PNG

 

Incremental and Dynamic Consent (docs.microsoft.com)

Power BI Content Pack is using Azure AD v2.0 endpoint which behaves differently than v1.0 endpoint which is widely in use. V2.0 endpoint provides dynamically added permissions instead of static permissions which are used with V1.0 endpoints.

The permissions set directly on the application registration are static. While static permissions of the app defined in the Azure portal and kept the code nice and simple, it might present a few issues for developers:

  • The app needs to know all of the permissions it would ever need at app creation time. Adding permissions over time was a difficult process.
  • The app needs to know all of the resources it would ever access ahead of time. It was difficult to create apps that could access an arbitrary number of resources.
  • The app needs to request all the permissions it would ever need upon the user’s first sign-in. In some cases, this led to a long list of permissions, which discouraged end users from approving the app’s access on initial sign-in.

With the v2.0 endpoint, you can ignore the statically defined permissions defined in the app registration information in the Azure portal and specify the permissions your app needs dynamically at runtime, during regular use of your app, regardless of statically defined permissions in the application registration information.

To do so, you can specify the scopes your app needs at any given point in your application time by including the new scopes in the scope parameter when requesting an access token – without the need to pre-define them in the application registration information.

Summary

User consents can be viewed/removed

  • Viewed from AAD portal and removed from users MyApps portal or with PowerShell
    • Remove-AzureADOAuth2PermissionGrant
  • All consents including admin consents by deleting application’s service principal (portal, powershell)
    • Remove-AzureADServicePrincipal

But I would like to see a similar possibility to manage or see V2.0 app consents than currently is available for v1.0 apps. Currently, V2.0 endpoint consents are not visible from the Azure AD portal (confirmed by Microsoft support). Referring to John Craddock presentation at Microsoft Ignite there is development in this area and a new version of the MyApps portal should be coming in near future which probably would provide the possibility to see (and remove) user consents from the MyApps portal.

More information

Application Types

Permission and Consent in AAD V2.0 endpoint

Comparison of V1.0 and V2.0 endpoints