Provide default scopes if client is not requesting a specific scope

The current behaviour is a conscious decision. Meaning that if you are a very powerful user in site A and generate a token, you can limit what "the token" can do in case it gets stolen (because a 3rd party security issue). By applying the admin role (inadvertently) we introduce an unnecessary risk.

I'd say that a client should contain all the roles it needs for functioning without depending on a certain user to have a preconfigured role. If my client needs admin access, I should add it to the client configuration. If someone doesn't have admin access it will be stripped from the token regardless what the client config says.

However, we could add an event that developers can subscribe to (or a hook alter) to alter the scope negotiation behaviour on a custom module. Would that work for you?

Some more context: https://www.youtube.com/watch?v=-xRBJvmg0qQ&index=4&list=PLZOQ_ZMpYrZtqy...

@lauriii do you have any thoughts on the arguments above?

I really like the patch and we have exactly the same need.

It leaves it open to you, to maintain the same security constraints if you want to. @elipsio

If you set a scope on the consumer, everything behaves the same. But our users have multiple roles and I cannot give every user all roles. Because the user is coming from an app, I also cannot set the scope in advance. The user does not know its roles while authenticating.

Therefore I have to leave the scope empty and fallback to the roles, the user is assigned in Drupal. This way I can dynamically grant users their correct role.

I kindly ask you, to rethink your position concerning forcing the scope to be a fixed role.

I cannot give every user all roles

This is crucial. Remember that you are not giving them roles, you are requesting scopes. When processing the token all requested scopes that are not present on the user will be dropped.

Hi,

When processing the token all requested scopes that are not present on the user will be dropped

Maybe I misunderstand the goal of the module, but this is the way I search to deal with :

I want to build a front-end with React, and the backend will be made with Drupal. The frontend can GET data, and POST it to CRUD on entities.
I tried to work with simple_oauth but I don't understand why the consumer allow specific roles passed by scope.
Example : In drupal, I have "basic user" and "manager" roles. When a user want to log-in from the React frontend, I don't know about this user. I can't build multiple consumer with specific roles because I don't know how to choose the right one... I don't know about the user.

If I have only one consumer with "manager" role, anyone using it will have the "manager" role. So even a '"basic user" only' can access REST method that are protected by permissions to be only accessible from "manager" users (for example "View user informations"). In the other hand, if the consumer is only "basic user" based, any manager who want to log-in will only have the "basic user" role and can't access the same REST method.

What is wrong in my logic ? You said that all requested scopes that are not present on the user will be dropped, but with a consumer "manager" based, a basic user can get a token and debug tell me that this user has "manager" role. If I try to call the REST method, he can access it...

Can you tell me if this module can't be used like that ?? Because I actually I think this is useful to use one consumer "per app" and give same permissions to all users of the app, but not to use it as login system with dedicated permissions based on roles of drupal users.

Thanks in advance for explanations and/or suggestions.

If I understand correctly what you'd need to do is

• configure no scope in your consumer
• always request both the "manager" and the "basic user" scopes in your request to get a token

simple_oauth will then issue a token that will have the automatic role "authenticated_user" plus the "manager" and / or the "basic user" roles according to the roles of the user who logged in.

I understand @e0ipso's reasoning, but I think it's not unreasonable/insecure to expect that all user's roles are included in the default scopes. I re-rolled the patch in a MR, which we will use in a project. I hope we can consider at least making this behaviour configurable. Having to pass all possible roles a user might have every time you request an access token is a bit cumbersome.

I also updated the Scopes field description to reflect the new rules.

FYI: In 6.0 we have introduced the possibility to specify default scopes per consumer, this is only applicable for the "Client Credentials" grant type. We decided not to support this for the “Authorization code” grant type, because the user needs to approve the scopes anyway.

With the new scope data model, it is now possible to define scopes and map them to a single permission or role. Also there is a hierarchy scope support, which means you can group scopes. This should give the desired flexibility to support various cases.

For more info see:

• https://www.drupal.org/project/simple_oauth/issues/2971579#comment-14597417
• https://www.drupal.org/project/simple_oauth/issues/3263590
• https://www.drupal.org/project/simple_oauth/issues/3283821
• https://www.drupal.org/project/simple_oauth/issues/3263611

I don't understand how this can be achieved in 6.0. The goal is to dynamically assign scopes based on the user role. The ability to add default roles per consumer does not achieve assigning default roles per user -- users of different roles may use the same consumer.

However, we could add an event that developers can subscribe to (or a hook alter) to alter the scope negotiation behaviour on a custom module.

I opened a new MR that does this: it adds hook_simple_oauth_scopes_alter(), allowing to alter the requested scopes.

The example in simple_oauth.api.php is what users would have to add to a custom module to achieve what this issue is about.

FYI: this issue becomes more important when using Dynamic Client Registration with Oauth, which I was implementing. In such a case the authorization code grant type is used and the client does not manually select any scopes but we need default scopes to be set otherwise the request becomes invalid.

I would prefer to add new features only to versions 6.0 and 6.1. Since altering scopes is security‑sensitive, test coverage is required. A dedicated test module that implements hook_simple_oauth_scopes_alter() and exercises the complete OAuth2 flow would be the most appropriate approach.