Managing user consent for applications using Office 365 APIs

Now that the new Office 365 APIs are available in preview and ready for you to build exciting applications, you might wonder how these applications can be managed.


There are several aspects to managing applications that are built by using the Microsoft Azure Active Directory (AAD) OAuth2 framework, and in this blog I want to briefly explain one important one.


Applications developed by using the AAD OAuth2 framework participate in the consent flow that AAD provides. As I mentioned in my previous blog (Using OAuth2 to access Calendar, Contact and Mail API in Office 365 Exchange Online), there are two types of consent:

·        User Consent, or consent provided by an end user

·        Admin Consent, or consent provided by an administrator


An application has to request which consent flow to implement.


If the application implements the user consent flow, any user in the Office 365 organization can install the application and give consent for the application to access the user’s resources.


If the application implements the admin consent flow, only users who belong to the Global Administrators group in the Office 365 organization can give consent to the application. That consent is then given on behalf of all users in the organization. Users do not have to provide an additional consent, and the application can access signed-on users’ resources immediately.


Note that an application can implement both consent flows. You can think of user consent as “Connect to my Office 365 resources”, and admin consent as “Sign my organization up to use this application”. The two models are not mutually exclusive.


The user consent flow is implemented by default for Office 365 organizations, but an administrator can change this default to prevent end users from installing applications.


This capability is not exposed in the Office 365 Portal or the Windows Azure Management Portal in AAD. To manage identities, an Office 365 administrator can use the PowerShell tools provided by AAD in addition to the portals. The administrator can use these tools to turn off user consent by using the following procedure.


To turn off user Consent


1.      Get the  Windows Azure AD PowerShell Module. This is available on TechNet.


2.      Connect to your Office 365 Tenant.


$msolcred = get-credential
connect-msolservice -credential $msolcred


3.  Check the current settings for allowing user consent.


Get-MsolCompanyInformation | fl DisplayName,UsersPermissionToUserConsentToAppEnabled


DisplayName                              : Contoso

UsersPermissionToUserConsentToAppEnabled : True


Note: A value of “True” indicates that users can consent to applications.


4.  Turn off user consent to applications.




5.      Verify that user consent to applications is turned off.


Get-MsolCompanyInformation | fl DisplayName,UsersPermissionToUserConsentToAppEnabled


DisplayName                              : Contoso

UsersPermissionToUserConsentToAppEnabled : False


Note: A value of “False” indicates that users cannot consent to applications.



Important: Turning off user consent impacts users in the following ways:

·        End users cannot consent to applications. This means that installed or native applications cannot be installed anymore in the Office 365 organization. It is not possible for an administrator to install a native application and make it available to all users.

·        Existing consents that users provided remain valid until the user either revokes the consent (for web applications) or uninstalls the application (for native applications).



How end users can revoke consent


I want to explain how end users can manage their consent. First, it is important to understand how applications record the consent. This is different for native applications (or applications that a user installs – sometimes also called native device apps) and web server applications.


For native applications, the consent is recorded on the device where the application is installed, as part of the RefreshToken. If the application is developed by using the ADAL client libraries, the RefreshToken is stored on the device. If an application doesn’t use ADAL libraries, the developer needs to handle storing the RefreshToken on the device.


For web server applications, the consent is recorded in AAD and is not part of the RefreshToken. While the RefreshToken still has to be managed, it does not actually carry any consent information.


This means that in order for an end user to revoke user consent for a device app, the user has to uninstall the application from the device or computer it is installed on.


For web server apps, the user can sign on with their organizational account and go to From there, they can see the applications that they have consented to and they can revoke access.


I hope this blog provided some more context around how consent is managed for applications that are consuming the Office 365 APIs. As always, please post additional questions.







Comments (14)

  1. Mark C says:

    Very informative, but could you explain one thing –

    After setting up an application (In my case Dynamics NAV 2013 R2 Web Client) i get an error – AADSTS50001: https://serviceURL/ does not have administrator consent, so how do i give admin consent to my new application?

    Thanks in advance

  2. Cith Go says:

    It is really helpful !!

  3. Cith Go says:

    Hi Matthias Leibmann~

    I have a problem. I want to login to Office 365 programmatically with different tenant, and use the PowerShell command you adviced : " Set-MsolCompanySettings -UsersPermissionToUserConsentToAppEnabled:$true "  to UserConsentToAppEnabled with ture

    But now the only tenant with admin role can login. Tenant without admin role has also fail to login and


    return error info: "Sorry, but we’re having trouble signing you in. We received a bad request."  and

    error code : "AADSTS50020: Calling principal cannot consent due to lack of permissions. "  


    Is there anything I forgot or need to do ?

  4. Sorry for late responses.

    To Mark Connolley and Cith Go as this might be the same issue:

    Does your application request admin consent with the authorization request. Currently you need to explicitly provide with authorization request a parameter that signals that your app wants to exercise consent on-behalf of all users in the org. This is done by adding "prompt=admin_consent" to the authorize request.

  5. Srikrishna Narasimhan says:

    Hi Matthias Leibmann,

     For us the multi tenant is not working at the user consent level. It says – "AADSTS50020: Calling principal cannot consent due to lack of permissions. "  

    Only admin user from another tenant is able to get access, but a normal user gets the above error. We dont want admin consent. Our goal is to implement One Drive For Business Multi tenant based on user consent

  6. Most likely some permissions your selected for your app are admin consent-able only, so a regular user cannot consent to a permission. If you tell me what permissions your app requests, I can tell which one. Or maybe better I list here the ones that require admin permissions. That is:

    For Exchange: Full Access to a users mailbox

    For AAD: Read directory data, Read and write directory data

    For SharePoint: Have full control of all site collections, Access your organization's SharePoint content as the signed in user.

    If you use any of those permission, your app can only be installed by an admin giving consent. Currently you indicate in the authorize request that you need admin consent by specifying prompt=admin_consent with the url.

    Hope this helps,


  7. Kirthi says:


    When i am trying to get the OAuth token for a User using the multi-tenant app, i am getting below error for only one particular user(normal user) "AADSTS90093: Does not have access to consent in office365". The same app works for other normal and admin users in the same organization.

  8. Hi Kirthi, could you please send us the complete error message, including the correlation/tracking Ids and timestamp you get from AAD?

  9. Kirthi says:

    Hi Matthias Leibmann,

        Sorry for late reply. Below link has the complete details of the error along with screen shot.…/27282558

  10. Eric says:

    Hi Matthias, do you know why our app wouldn't have the option to 'remove' in the drop down menu. It's only showing 'get info' and 'report problem'. We've configured both a native and web server app and neither have this option?

  11. @Eric, is this in the Office 365 AppHub? If yes I believe the functionality to remove is not yet there. Do you see the app at You should be able to remove from there. Or are you saying you cannot delete from

  12. Ryan Marchant says:

    Does anyone know how a user can restore consent to an application that they previously revoked consent for from the portal?

  13. Hi Ryan, the only way is to go through the authorization flow again for this user. The app should go back to the authorize flow if an error occurs getting an access token that indicates app is not authorized anymore.