No way to limit allowed scopes for a consumer using client credentialss

This is a valid point, we should definitely reintroduce this feature. The question is how? We could add an extra responsibility on the default scopes, so it limits the scopes per consumer or we can introduce an additional field where we can specify allowed scopes. I’m open for suggestions.

I went ahead and made the default scopes limit the allowed scopes per consumer. Can somebody please review?

Thank you so much for working on this! From looking at the code that is exactly what I had in mind, just wasn't sure you would be open to that change. That's really great 👍️

I had meant to test this last week, but that didn't work out and I'm off this week, but will try to prioritize checking this out next week.

Tried out the code now and it works exactly as expected. The tokens now automatically get the scopes selected for the client/consumer and any additional scopes are rejected.

I only have one question: When I was testing I initially set up my client to have no scopes at all. In that case this validation logic is not applied because it is within the

    if (!$client_drupal_entity->get('scopes')->isEmpty()) {

block. Even though it's not a very practical scenario, I would have expected the created tokens to have no scopes in that case instead of any requested scopes.

Will set to needs work for that.

But thanks again for working on this, really much appreciated.

One other aside, as I don't know where else to mention this: I built a tiny module that allows creating client credential tokens via the Drupal UI, to save administrators having to use Postman or whatever to do that. Since it's fairly generic I am planning to contribute it. I am presuming, though, since it's somewhat of a niche use-case that you wouldn't want to have that in Simple OAuth proper so I am planning on a separate little module. But wanted to check with you first, just in case that's something you'd be interested in having directly as part of the main module.

If there are no scopes requested and no scopes are set on the consumer with the client credentials, in 5.2 it will fallback on the default user (set on the consumer), with 6.0 you won't have any access. We definitely need to address this in 6.0, I think we should grant all scopes that support client credentials if no scopes are set on the request and consumer.

Regarding the tiny module, it would be interesting to have some testing/debug submodule available that does this. I would be open to add this to the module.

That's fair enough. I think it's a bit unintuitive that if you do have a consumer with client credentials and no scopes initially and select a single scope it actually reduces the amount of possible scopes for that consumer. But, yes, that scenario will only really happen during initial setup or testing, it's not really a sensible "production" configuration to have a client credential consumer with no scopes. Maybe we could amend the description, though, to make people aware of this nuance? In any case, that was the only reservation I had so marking RTBC.

That's great regarding the module, I will open an issue for that, hopefully will get around to that this week, let's see.

To be in line with the OAuth2 spec: https://datatracker.ietf.org/doc/html/rfc6749#section-3.3
I have made the token endpoint require the token scope parameter when there is no default scopes available on the client/consumer when dealing with the client_credentials.

Could you please review my last commit?

Hey there, tested the last commit now, sorry for taking a bit.

I tested three scenarios:

1. No default scope in consumer and no scope in request -> { "error": "invalid_request", "error_description": "The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed.", "hint": "Check the `scope` parameter" }
2. No default scope in consumer and scope in request -> token with requested scope granted (again, this is the case I find suboptimal, but it's not a realistic production use-case anyway)
3. Default scope in consumer and no scope in request -> token with default scope granted

So looks perfect from my point of view

Thanks for reviewing/testing @tstoeckler!

Automatically closed - issue fixed for 2 weeks with no activity.