-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Add a basic authorization server policy for scope validation #187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@Clem69B There are many generalized recommendations in RCF 6749, this being one of them:
The preceding statement does not translate to:
I do understand the need for custom policies but this would be custom functionality that would be implemented in an OAuth 2.0 Provider product. This project is strictly focused on implementing the various OAuth 2.0 / OIDC specifications. This custom behaviour (policy enforcement) would need to be implemented in an OAuth 2.0 Provider product that ultimately extends from this project / framework. I hope this makes sense? |
Hello @jgrandja, Thanks for your answer, it's make sense regarding this ticket name and description. But, the reason behind this ticket is still actual, and, I think, focus on your project : If I want to do this myself, how can I do it with this framework ? What are the entry points ? I have explored the source code, and actualy, I have seen no suitable method to do this, except rewrite a lot of things. So I have written a specific ticket to be clear on my situation and my need, but I think that is a more global need and can be in the framework scope : How a third party integrator can build its own policy using your project ? |
Expected Behavior
The RCF 6749 contains this proposal :
A basic policy may be avaible, in order to filter scopes asked by client regarding the GrantedAuthority of the authenticated user (ressource owner) before the consent (in case of authorization_code with consent procedure).
Current Behavior
No comparaison or filtering are made between user GrantedAuthority and scope asked by the client.
So tokens are delivered regardless of the user rights limitation.
Context
I have a custom UserDetailsService and authorities specified with authorized scope for the user.
The text was updated successfully, but these errors were encountered: