Setting up some machine to machine relations in OAuth reveals some unexpected and (from our point of view) undesireble behavior. Should we really implement hooks to fix this?
Omitting scope in the request returns all granted scopes for the client (security risk)
Explicitly requesting the empty scope “”, returns all granted scopes (seems wrong)
Explicitly requesting one scope. “read”, returns all granted scopes, “read” and “write” (seems wrong)
Is this really the behaviour we should expect from Auth0?
We are relying on requesting as narrow scopes as possible for our machine-initiated communications, partly because the generated tokens may be cached for longer spans of time.
What you are seeing is the expected behavior. With the client-credentials grant, Auth0 returns all the scopes granted to the application, regardless of the scope parameter. The rationale behind this decision is that the requester already has the credentials (the “keys to the kingdom”) to ask for any scope, so there’s no point in restricting the scopes by default.
If your particular use case causes the issued tokens to be less secure than the client_id/client_secret pair, you can use a client-credentials hook to restrict the scopes of the returned token to those that the client asked for, with something like this:
module.exports = function(client, scope, audience, context, cb) {
var access_token = {};
access_token.scope = scope;
if (client.id === 'xxxxxx') {
// restrict scopes to those requested by the application
var requestedScopes = (context.body.scope || "").split(' ');
// return only the intersection with those scopes
// that were originally granted (the scope parameter)
access_token.scope = requestedScopes.filter(x => scope.indexOf(x) !== -1);
}
cb(null, access_token);
};
Ok, this is what I suspected and good that you could confirm that. I have tried a similar hook as a proof of concept for our roadmap. I appreciate that the client will have at its power to request any scope it wants. However should the client want a smaller scope, for minimizing damage if a token should be forwarded and/or misused by mistake, I do not se the point of not supporting that.
Thanks, we will go ahead using this kind of logic.
I am thinking we restrict this behavior not to clients (as your example does) but to the grant type being ‘client_credential’. I am assuming this behavior only exists for the Client Credentials grant type?
The Resource Owner Password grant has a similar behavior, with the same reasoning behind it. But keep in mind that in this case you will have to code a rule, as the client-credentials hook will not execute for the ROPG.
I encourage you to leave feedback at Auth0: Secure access for everyone. But not just anyone. describing the use case where this behavior is less than ideal. The feedback is analyzed by the Product team and drives the development of the product.