Issues with Scopes assignment in Azure AD

Surbhi Nijhara 36 Reputation points
2020-06-19T07:43:12.387+00:00

Hi,

There are 2 issues seen while issuing token from Azure AD OAuth2.0 as below:

Following apps are registered in AD:

Product-A with Scopes: product:A:view, product:A:edit

Product-B with Scopes: product:B:view, product:B:edit

****Issue 1: All scopes from a single app gets included in the token, even if the request is for one scope only.****

Suppose, Client app is added with both Product-A scope product:A:edit and product:A:view .

If a token is requested with product:A:view scope, the token response contains all the scopes from the Product-A, i.e. both product:A:view and product:A:edit scopes are assigned to the token.

Basically, scope is not acting as a filter.

Issue 2: Scope included only from one app, even if the request is for multiple scopes from different apps.

Suppose, Client app is added with both Product-A scope product:A:edit and Product-B scope product:B:view

If a token is requested with both product:A:edit and product:B:view, the issued token contains the scope of only one app (app-id whose scope appears first on the scope parameter of token endpoint api) for e.g. only product:A:edit is assigned to the token.

Are these known issues or is something missing in the configuration. Any help is appreciated?

Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
22,172 questions
{count} votes

Accepted answer
  1. AmanpreetSingh-MSFT 56,666 Reputation points
    2020-06-23T18:24:25.04+00:00

    Hi @SN-7656 If you have added the permissions under API permissions blade of the app and granted admin consent, you will get those permissions in the token even if you do not explicitly specify within your token request. Please remove the permissions from there and just keep the scopes under Expose an API blade only.


    Please do not forget to "Accept the answer" wherever the information provided helps you. This will help others in the community as well.


3 additional answers

Sort by: Most helpful
  1. AmanpreetSingh-MSFT 56,666 Reputation points
    2020-06-19T09:58:40.833+00:00

    Hi @SN-7656 Please find below the answer to your question:

    Issue 1:

    You can refer to below call. In this case, I have requested a token with both "read" and "list" scopes. However, if I remove read scope from the request body, I am getting only the list scope in the token.

    10413-untitled.png

    Issue 2:

    This is expected. In a token request you can only include scopes from one application at a time. To include scopes from a different application, you would need to make a separate call. If you include scopes from different applications in same call, it fails with error: AADSTS28000: Provided value for the input parameter scope is not valid because it contains more than one resource.


    Please do not forget to "Accept the answer" wherever the information provided helps you. This will help others in the community as well.


  2. Surbhi Nijhara 36 Reputation points
    2020-06-24T10:17:29.003+00:00

    @amanpreetsingh-msft , Thanks much for responding.

    Expose an API works technically but, by design, does not seem to be the right way for a using Client App.

    An App can be registered as follows:
    1)To represent an API or a resource app, which exposes the protected API. This is done by Exposing API as described in Register app to represent an API - Step 7 and 8.
    2)To represent a Client App, which adds the required APIs or resource apps. This is done using API permissions as described in Register app to represent Client App # Grant Permissions - Step 3 and 4

    A user is aware of its client app and using client id/secret, the user requests for a token to access one of the protected APIs.

    If we go by the way you suggested, this will mean to configure apps in one of the below ways:
    a. A client app will need to expose all the APIs by adding scopes explicitly. I do not see the purpose of registering apps to represent APIs in this case
    OR
    b. Represent each app which is supposed to represent an API, as a client app. Then only the token request can use the client id. However, it should not be this way.

    Both ways are not correct by design.

    Again as per documentation, the permissions should be added to the client app using API permissions (and not through Expose an API). If all permissions are assigned in the token even if a single permission is requested, then this seems to be wrong.

    Do you agree on my understanding? Will appreciate your thoughts as a reply here.

    0 comments No comments

  3. AmanpreetSingh-MSFT 56,666 Reputation points
    2020-06-24T12:19:24.497+00:00

    @surbhinijhara API Permissions needs to be added if the scopes are exposed in one app and you are trying to add those scopes to another app. If you are requesting token for same app with scopes exposed, you don't need to use API permissions. Scopes represents permissions and used for authorization by the federated application, as long as you are getting required scopes in the token, you should be good.


    Please do not forget to "Accept the answer" wherever the information provided helps you. This will help others in the community as well.


Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.