Adds possibility to have allowed scopes restriction per client

[Swop]

Hi,

Currently, if an access token request is made by a client, without any provided scopes, the default scopes (declared in the supported_scopes option in the bundle configuration) are added to the token.

As I read the OAuth2.php code, I understand that if no scope is given, the "default scopes" are assigned to the token. But I think that "default scopes" and "supported_scopes" are two different things.

If I declare an "ADMIN" scope in the supported_scope option, any clients which doesn't ask for a specific scope will be "ADMIN granted".

I understand that scope is needed in auth-code grant flow, because the user has to allow the client to access his info with the specified scopes, but for client_credentials grant flow (which IMHO could be used by any clients to be able to retrieve some useful information from the API), no scope is required in the access token request.

Maybe it's my fault and I don't know how to use it, but I thinks it's could be very useful to declare the allowed scopes during the client creation (like the allowed grant types), to be able to secure some controllers from third party clients.

It could be done by checking the client id, but it seams better to deal with scopes (aka Symfony roles in this case) here.

What is your opinion about that ? Is there a thing I missed or didn't understand ?

[Spomky]

Hi,

In fact, this is not supported by this bundle, but by oauth2-php itself.

I have worked on this fonctionality, but it is only available for the whole server and not by clients. Look my PR at FriendsOfSymfony/oauth2-php#45.
It should be quite easy to extend it on clients. However, the interface has to be changed.

[Spomky]

I have just updated this PR.
Now you can set the scope policy and default scope in the server or in each client if needed.
If client have a scope policy (scope policy is not null), the scope policy of this client will be used. Same for default scopes.

[Swop]

This is great ! 👏

I hope that this will be merged soon...

[pyrech]

What's the status of this issue? It seems that the related PR will never be merged but the issue is still present. The default scope should really be different than the supported_scopes config

[Swop]

I totally agree...

Don't know if anyone of the FOS developers is interested to fix this issue... That make me sad :-(

[liverbool]

Wait for FOS response. @stof

[pedrocasado]

any updates?

[codeMonkeysBe]

@stof any ideas on this ?

[oniric85]

+1 Looking forward for this

[Spomky]

Hi all,

I would like to let you know the latest news concerning this issue.
As I explained in the discussion you can read on the PR I submitted, the problem when we want to add new features is that it creates multiples BC breaks. This is mainly due to the oauth2-php library.

That is why I closed my PR and decided to create new modern library and bundle.
You can get more information on this page (posts at the end) or on the repositories of these projects (library and bundle).

These projects already support this feature and a lot of other features at the same time such as CORS (#346), custom exception messages (#337, #305), public/unregistered clients (#282, #256)...
But I have not marked them as stable at this moment even if they are quite mature: I need more feedbacks.
It will be great if you could test it and report me issues or questions (and I know you will have questions as the documentation is not yet complete 😉).
Then, this bundle could be updated using my work as proposed by other stakeholders and we will be able to close this issue.