Managing user consent for applications using Office 365 APIs

  • Article

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.