Sign ins requests are using Microsoft Graph as a resource while not requested

Describe the bug Our application is a B2B application, our customers are large companies, they use Microsoft as an identity provider for their employees.

Our application is using the latest version of the MSAL library to let employees authenticate with their Microsoft account, we then provide the access token to our backend so the user can be authenticated within our product. After that, we don’t use the MSAL SDK or the access token to do anything from the mobile app. We don’t even need to refresh the token. We provide the scope openid (the default scopes profile and offline_access are then added to our sign in request by the MSAL Library via the common library).

This works fine for most customers. Except we have some customers who are blocking Microsoft Graph resource from being used and that prevent their employees to connect. When looking at our sign in requests, we’ve found out that Microsoft Graph is used a resource in our sign in requests while we didn’t request it or used anything that could lead to that.

We tried to use the sample and remove the call to Microsoft Graph, sign in requests to the Azure application configured in the sample are also recognised as using Microsoft Graph API, when putting our configuration in the manifest and the json configuration we also still have the resource Microsoft Graph API used… Our customers can’t sign in…

This issue is happening on the MSAL Library for objective C as well.

We think that the MSAL library is doing something that make it use the Microsoft Graph API, do you have any information about that? Is it normal? Is it possible to disable that on our side?

Smartphone (please complete the following information):

• Device: any devices
• Android Version: from API Level 23 to 30
• Browser: tested with Chrome & Edge as default browser
• MSAL Version: latest version (2.0.6)

To Reproduce Steps to reproduce the behavior:

1. Use the provided sample project: ms-identity-android-kotlin-master-edited.zip (it is the official Kotlin sample project but with the openid scope forced and the call to graphApi disabled.
2. Sign in with any Microsoft account
3. Go to the administration
4. Find you user
5. Go to Sign-ins
6. Check that the sign-in request is using the Microsoft Graph API as a resource

Expected behavior Sign-ins with MSAL library that don’t use Microsoft Graph API directly shouldn’t use Microsoft Graph API.

Actual Behavior Any sign-ins with MSAL library that use Microsoft Graph API as a resource.

Screenshots The sign in request that use Microsoft Graph:

[CPonchet]

@iambmelt thanks for the update and again, thanks for your time.

[iambmelt]

@iambmelt first thanks for taking some time 😃. Today, we are using an enterprise app deployed on the AAD Marketplace. This app is using mainly the graph for integrations (getting and pushing info). In some cases, our customers are using conditional access to limit the use of Office (off-site mode). In this particular case, we (as an application) are not authorized to generate a refresh and access token but only an id-token. In this case, we wish we could ask only for the openid/profile in the scopes without the offline_access. We performed some tests on our end with a basic app (aka without the offline_access) and passing the .default scope seems fine. To avoid getting multiple applications on our side (and for the customers too), is it possible to not ask in some cases the offline_access scope? Available if needed, I would be pleased to exchange on the subject if expected.

Thanks for this additional info, @CPonchet - I’m going to forward this request as well as the context you’ve provided over to our Program Management team to evaluate this work for inclusion on our roadmap. Thanks!

/cc @hamiltonha

Hi @CPonchet - I wanted to let you know that I’ve sent this item over to our PM team and it is on our backlog for Community Feature Asks. This backlog is prioritized quarterly, so I cannot give any estimate or commitment on it at this time

Edit:

For MS Worktracking, see ADO Item tracking this ask (corpnet reqd)