All preauthorized permissions are returned regardless of the requested `scopes`

[jiasli]

This could be the designed behavior of the underlying API. I am only creating this issue for tracking and clarification purpose. Feel free to close it.

Describe the bug All preauthorized permissions are returned regardless of the requested scopes

To Reproduce Steps to reproduce the behavior:

1. Create a PublicClientApplication with Azure CLI's client ID 04b07795-8ddb-461a-bbee-02f9e1bf7b46.

2. Call acquire_token_interactive with scopes as ['https://graph.microsoft.com/User.ReadWrite.All']. The Azure CLI command is

   az login --scope https://graph.microsoft.com/User.ReadWrite.All

   https://github.com/Azure/azure-cli/blob/b00483c1a1cd17053af5c483f62b11c829f4c27d/src/azure-cli-core/azure/cli/core/auth/identity.py#L160-L166

3. See the scope property of the result be 'email openid profile https://graph.microsoft.com/AuditLog.Read.All https://graph.microsoft.com/Directory.AccessAsUser.All https://graph.microsoft.com/Group.ReadWrite.All https://graph.microsoft.com/User.ReadWrite.All':

Expected behavior Only requested scopes are returned, in such case https://graph.microsoft.com/User.ReadWrite.All.

What you see instead All preauthorized permissions are returned.

The MSAL Python version you are using 1.26.0

Additional context Add any other context about the problem here.

[bgavrilMS]

This is by design @jiasli - the token issuer (AAD) has this behavior to reduce the communication steps with the client.

This is also one of the reasons why we strongly recommend each app (e.g. Azure CLI) to be mapped to a single AAD app registration, and not to have 1 app registration for many apps.

[rayluo]

Also, there is really nothing the client-side can do here, based on this OAuth2 quote.

The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions. If the issued access token scope is different from the one requested by the client, the authorization server MUST include the "scope" response parameter to inform the client of the actual scope granted.

[bgavrilMS]

For reference, the behavior of ESTS in regards to scopes and Conditional Access (CA) is:

For the scopes you requested explicitly:

• If there was a CA policy applying to one of those scopes we will challenge/block the call.
• If there are no CA policies applying your call will be successful and you will get a token with at least all the explicitly requested scopes.

For the other preauthorized (by tenant admin or by the user) scopes which were not requested:-

• If there was a CA policy blocking one of those resources we would drop that scope without blocking the call.
• If there are no CA policies applying we will give those scopes back as well, which is what you are seeing

For example : you request “User.ReadWrite.All” and Entra enforces CA for that scope. But there are other scopes like AuditLog.Read.All that are preauthorized and no CA policies apply for them, so you got that back as well.