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.
Set-MsolCompanySettings -UsersPermissionToUserConsentToAppEnabled:$false
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 https://myapps.microsoft.com. 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
Anonymous
June 05, 2014
Yay! nice articalAnonymous
September 03, 2014
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 advanceAnonymous
September 03, 2014
It is really helpful !!Anonymous
September 03, 2014
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 ?Anonymous
September 16, 2014
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.Anonymous
October 09, 2014
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 consentAnonymous
October 10, 2014
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, MatthiasAnonymous
December 03, 2014
Hi 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.Anonymous
December 05, 2014
Hi Kirthi, could you please send us the complete error message, including the correlation/tracking Ids and timestamp you get from AAD?Anonymous
December 07, 2014
Hi Matthias Leibmann, Sorry for late reply. Below link has the complete details of the error along with screen shot. stackoverflow.com/.../27282558Anonymous
January 27, 2015
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?Anonymous
February 07, 2015
@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 https://myapps.microsoft.com? You should be able to remove from there. Or are you saying you cannot delete from https://myapps.microsoft.com?Anonymous
May 01, 2015
Does anyone know how a user can restore consent to an application that they previously revoked consent for from the https://myapps.microsoft.com portal?Anonymous
May 05, 2015
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.Anonymous
November 01, 2016
@Mattias, Thanks for this. Very useful. I'm trying to revoke OAuth access to an app I've created. > For web server apps, the user can sign on with their organizational account and go to http://myapps.microsoft.com. From there, they can see the applications that they have consented to and they can revoke access.I've gone to http://myapps.microsoft.com and found my app, but it does not have a Remove link in the dropdown like some of the others do. How do I get the Remove link to show up?Anonymous
November 08, 2016
You can enable/disable this feature through the Admin Center, Settings, Services & Add-Ins. Under Integrated apps.Anonymous
January 10, 2017
I don't understand. How to I give consent?Anonymous
November 09, 2017
How do i revoke access via code in my web application? so that the User consent screen comes up again on requesting- Anonymous
November 13, 2017
You cannot revoke access in your code, but the user can revoke access at myapps.microsoft.com.
- Anonymous