Hi Jonathan. Welcome to the community!
In a machine-to-machine token request, the client application (“Foo”) contacts Auth0 directly (server-to-server) using the
/oauth/token endpoint and the client credentials grant. This token request is independent of the (interactive) authentication request for the user (which is not server-to-server, instead it’s interactive and happens in a browser). So essentially you’d have two separate token requests:
- One interactive (
/authorize, via the browser) to authenticate the user and, optionally, to get an access token for a custom API. The user will see a consent dialog only if the app if third-party or if the custom API is forced to show consent (or if the app is running in
localhost). The access token gives the application access to the custom API (backend server) on behalf of the user.
- One server-to-server request, using the client-credentials grant, where the application gets a (separate) token to access Auth0’s management API (for the scopes that were granted to the app). This token is issued directly to the application, with no references or involvement from the user. It gives the application global access (scoped to whatever scopes you’ve granted to the app). So the app can access information for every user (e.g
read:users), and not just for the current user.
From the consent you are getting, it seems that you’ve added some management api scopes and audience in the authentication token request (the one involving the user). This is a different situation, where the user approves the application to access their data (e.g.
read:current_user), and in these cases there will be a consent dialog involved.
The client-credentials grant would be useful when the client app is a server-side app that can securely keep its client secret secured.
Hope that clears things up a bit.