After configuring several APIs to be granted access, with limited permissions, to a handful of machine-to-machine (M2M) applications, the following observations have been made:

• If a token is requested by an M2M app, and no scopes are specified in the request, then the access token returned has all granted scopes for the given M2M app as expected.
• If a token is requested by an M2M, and a subset of scopes are specified at the time of request, then the access token will still include all the scopes enabled for the M2M app.

The second bullet point seems like unexpected behavior. This article clarifies whether it is possible to retrieve an Access Token with a subset of approved scopes for a given M2M app.

The scenario that generated the above results:

• Make a call to a custom API using the Client Credentials flow.

  curl -sS --request POST \
  --url "https://auth.dev.example.com/oauth/token" \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=client_credentials \
  --data client_id="abc123def578" \
  --data client_secret="**REDACTED**" \
  --data scope="read:claims" \
  --data audience="api2"

• Inspect the returned access token and confirm all scopes are returned, even if a subset of scopes were requested. In this example, there could be an expectation to get back only the "read:claims" scope that has been specified. However, all of the API scopes will be returned.

• Auth0
• M2M Token
• Scopes and Permissions

This is expected behavior. During a client credential flow, the scopes returned will always be the full set of authorized scopes for the M2M app. This is true even if a subset of the available scopes were requested.

Use Rules to manipulate the scopes that are returned. This can be done by manipulating the context.accessToken object: 

• Context Object Properties in Rules
• Sample Use Cases: Scopes and Claims

As of May 2026, this parity gap has been closed between Rules and Actions. This can be accomplished now with the new Credentials Exchange Actions Access Token Scope Interfaces. These new interfaces allow administrators to customize the scopes to be considered when the access token is issued by writing Credentials Exchange Actions, considering the restrictions based on API and Client Grants definitions. See this changelog post for more information.