The MicrosoftConnector requires 7 scopes:
- Calendars.Read
- Files.Read.All
- Mail.Read
- offline_access
- openid
- profile
When Azure requires admin consent (e.g., a tenant wants to use the “Admin Consent Flow”), an admin on Azure's side must consent to the top three scopes (called Application scopes). The bottom four are Delegates (the user has to accept those).
When we generate the OAuth URL, we specify the scopes that need to be included in the code and those that will be attached to the access token. That way, when a user authorizes the connector, they’d only see the Delegated scopes/permissions.
The issue was that Microsoft rejected all access tokens generated for users, even though we had already specified the scopes ahead. MS was only setting the delegated scopes in the access token, even though the super admin on the MS side has granted access to the remaining Application scopes. It should be sending all scopes since we have the two-way grant.
However, for MS to send those three remaining scopes, the grant must be approved from an enterprise level, and there’s no manual way to do it from Azure. Part of the flow to authorize the connector is to ask an Azure admin to approve those Application scopes (either for a user or a whole tenant). By sending a manual request to the admin to approve those scopes, MS adds a section to the API Permissions specific to those Application scopes and then starts adding those to the access tokens. This section (an example from our Azure):
For future references: If a tenant is having issues getting the MS connector to work and this tenant requires admin consent, send the Authorization request without the admin consent so the Azure admin can approve those permissions. Then enable the admin consent flow.
Related to
Updated