I have a few questions related to Clients:
ClientEntityInterface has no getSecret method and the related trait has no $secret property, where should the secret be stored?ClientEntityInterface has nothing to say about scopes, but ScopeRepositoryInterface:: finalizeScopes receives a ClientEntityInterface to help make decisions about scopes. Are we implementers intended to connect those arguments ourselves, outside of the context of oauth2-server, in order to make those decisions? Perhaps a ValidScopes entity combining grant type, the client, valid scopes (among other domain related relationships)?(Regarding question 1, I could certainly add whatever methods I like to my ClientEntity implementation, but then I'd be coding to an implementation and not to the provided interface.)
The ClientEntityInterface doesn't have a getSecret method because the library doesn't need to know the client's secret. The only time the client secret is relevant is during your implementation of ClientRepositoryInterface:: getClientEntity whereby you can validate the client secret along with the client ID at that point.
Regarding your second question could you please explain it a little more, I'm not quite following the scenario you're looking for
Hi @jeremykendall, please could you provide some more context with regards to your second point so we can progress this issue? Many thanks.
Closing this as haven't heard back from @jeremykendall. If you still require assistance, please feel free to comment on this issue and we will reopen it so we can follow up. Cheers
@alexbilbie @Sephster
I guess that @jeremykendall meant that as of today it is not possible for a client to have scopes in their properties so it is not possible to validate that one client has the right scope access. This is specially annoying with the client credentials grant (so machine-to-machine communication) where scopes could be a sort of ACL.
For example my OAuth server defines scope1 and scope2. One client have access to scope1 so if he tries an auth request (or token request) with scope1 and scope2 the server would not grant access because scope2 is invalid for that client.
I found another implementation (in Java) where this is possible -> http://projects.spring.io/spring-security-oauth/docs/oauth2.html#configuring-client-details.
Let me know if this makes sense to or not. Perhaps I am missing something.
@Sephster Small reminder. Please let me know if I am mistaken or something.
Hi @B-Galati - sorry for not seeing your question. I think this is still possible given the current state of the package although we don't specify how to do this ourselves.
If someone wants to restrict a client to certain scopes, you could use a scope to client ID mapping in your database and query the client ID stored in the client entity.
This would require a bit of work from your end to implement but we've intentionally left the package flexible, using interfaces and abstract methods where ever possible, to give you freedom to mould it to your requirements.
There is no concrete implementation of finalizeScopes provided as the validation for scopes could mean different things for different devs/use cases. Some might not want to restrict by client for example, and instead do it by user ID.
An example of a finalize scope method is given in our examples which is just listed an an example to inspire you to roll your own:
Hope this answers your question.
@Sephster You're right. it's clearer now.
Thank you for this great answer :-)
No problem. You're welcome!
Hello, leave come back this subject. My scenario is like the one in @B-Galati , but I'm not understand with implement this in method finalizeScopes in ScopeRepository class, when verification it is based in an Client. Could you show an example of this? How should I deny the request? Client1 should only have access to scope1 resources.
Thanks.
@rodriigomedeiros which grant are you using?
Hello @Sephster , I'm use Authorization Code.
In the auth code grant, when the user grants permissions to access their resources, they should be shown a list of scopes that have been requested by the third party.
If they are happy with granting these scopes, the user will authorise the request and an authorisation token will be created. This will contain details on the permissible scopes.
It can then be exchanged for an access token which is a JWT that also contains the permissible scopes. When decoding the JWT, you can retrieve the scopes in your application code and user these to control who can access what. This library doesn't handle this section of your application as it is outside the scope of this library's remit.
I hope this helps!
Understood @Sephster, I implemented what was missing in my case. Thank you!
@rodriigomedeiros FYI I聽did that -> https://github.com/EnMarche/en-marche.fr/blob/6ca2a7906ffa9471a703a78c35a31adfba9d4f6d/src/OAuth/Store/ScopeStore.php#L22-L43
@B-Galati , cool. In my case, it is not all customers that implement scope because until then all were self consumption. So, I had to implement differently. Here is a small sample of my solution.
The main point is in the oAuthController class, line 54-68. In addition, I created a middleware for when the client has scope defined in my registry, it necessarily needs the correct scope to access the resource.
https://gist.github.com/rodriigomedeiros/37783dc318061482defe4846f1d851bc#file-oauthcontroller-php-L54-L68
Most helpful comment
Understood @Sephster, I implemented what was missing in my case. Thank you!