Client Credentials using OAuth 2.0 does not respect override scope-setting in API

Bug description

Client Credentials using OAuth 2.0 in the interactive developer console does not respect if an API is configured to override scope (In the Azure Portal: API -> Settings -> Override scope). It seams that it is always using the default scope configured for the authorization server (In the Azure Portal: OAuth 2.0 - Default scope).

Reproduction steps

1. Create authorization server that allows Client Credentials, and set default scope to for instance https://graph.microsoft.com/.default.
2. Create API with override scope set to something else, for instance api://my-app/.default.
3. Navigate to developer portal.
4. Click “Try it” and chose “clientCredentials”.

This results in an Authorization header with a bearer token issued for https://graph.microsoft.com:

{
  "typ": "JWT",
  ...
}.{
  "aud": "https://graph.microsoft.com",
  "iss": "https://sts.windows.net/{tenantId}/",
  ...
  "appid": "id for client application, configured in APIM OAuth server.",
  ...
  "tenant_region_scope": "EU",
  ...
  "ver": "1.0",
  ...
}.[Signature]

Expected behavior

The authorization header should be set with a bearer token issued for my-app, for example:

{
  "typ": "JWT",
  ...
}.{
  "aud": "{id for resource application.}",
  "iss": "https://login.microsoftonline.com/{tenantId}/v2.0",
  ...
  "azp": "{id for client application, configured in APIM OAuth server.}",
  ...
  "roles": [
    "{role value configured for resource application and granted to client application."
  ],
  ...
  "ver": "2.0"
}.[Signature]

Is your portal managed or self-hosted?

Managed

Environment

• Operating system: Windows
• Browser: Edge
• Version: 83.0.478.56

Additional context

It seams that oauthService.ts is only making the browser opening https://${location.hostname}/signin-oauth/credentials/${authorizationServer.id}. I cannot find anything that is passed along to .../signin-oauth/credentials/... (the backend that makes the actual request for getting the token) that can be used for picking up what API the token should be used for, and hence it cannot make use of any overridden scope that is defined in that API.

[azaslonov]

UPDATE: The fix is in the release pipeline and should land in every region in the next couple of weeks.

[azaslonov]

Backend deployed. Added respective changes to the client, which should be shipped by the end of this week.