Default scopes for a client when scope parameter is not provided

[trung]

First of all, thanks for the awesome implementation.

Per OAuth2 Specification, section 3.3

If the client omits the scope parameter when requesting
authorization, the authorization server MUST either process the
request using a pre-defined default value or fail the request
indicating an invalid scope. The authorization server SHOULD
document its scope requirements and default value (if defined).

Currently, if the client does not specify any scope when calling /oauth2/token, an empty scope is returned. It can be understood that empty value IS the default value.

However, in some scenarios (using client_credentials grant for legacy app-to-app), the client is unable to include scope in the request so it expects the authorization server to return all of its assigned scopes.

Ability to configure default scopes for client would allow not only making the above possible but also reasoning better with the spec .

[aeneasr]

Currently, if the client does not specify any scope when calling /oauth2/token, an empty scope is returned. It can be understood that empty value IS the default value.

No scope is the default value.

You can add permissions to the scope during the consent step. This is not possible for the client_credentials grant.

[ngrigoriev]

I actually second this feature request. And the reason for me is Oathkeeper. It has a great option of enforcing the scopes, which is very cool if you have multiple backend apps and multiple APIs. However, it is hard to enforce the scope when it is empty (default). Oathkeeper cannot automatically discover the client default scopes in Hydra and substitute them for the purpose of the token validation. There seems to be no convenient way to inject it without hijacking the token introspection endpoint.

Indeed, the consent provider could do that but there is no option for client_credentials grant. Which, again, makes Oathkeeper scope enforcement useless.

It would be really nice to have an option in Hydra that allows to substitute the default client scopes for the purpose of the token introspection to "unify" the token validation logic. I was thinking about adding an option to Oathkeeper for that (calling GetClient on Hydra) but this is problematic: this is admin API, more sensetive than the public one. Plus two roundrips instead of one...Plus non-standard API instead of plain introspection call.

[aeneasr]

@ngrigoriev are you talking specifically about the client credentials grant?

[ngrigoriev]

@aeneasr Yes and no. I would like to have the effective scopes exposed to Oathkeeper for decision making regardless of the grant type. However, today I can only do it for the grant types other than client credentials, through login/consent provider, by calling GET /client and then setting the scope if the actual scope is empty.

So, maybe this can be addressed differently, in fact, and add a "pièce de résistance" to Hydra - a callback similar to the login request that is made when the client credentials grant is executed? This way there will be an ultimate way to customize the token properties according to the needs of the developer.

[aeneasr]

Like this? #1748

[ngrigoriev]

I think #1748 goes too far in terms of customization methods :) In my opinion, Hydra could be made much more powerful with two additional integration API calls:

1. An equivalent for "consent" request sent from Hydra to Login/Consent Provider, but for the client credentials grant. That's where we could customize the token any way we want.
2. A similar call before refresh token is handled (outside of the scope of this particular issue, of course) - this would give the developer a potential ability to block the token refresh without having to proactively call /revoke before. Basically, to deny the refresh because of some custom condition.

[aeneasr]

This is resolved on master and will land in 1.9