You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So, this times I got to add scopes verification and all to different endpoints security (paths).
I want to have multiple scopes for a same securityDefinition to be able to access one route, but I just want to check if the token have at least one of this scopes.
It could be really better if the scopes definition can be an object, with more specifications possibilities, let me explain better.
As you can see, this is not the more convenient way to do this, if you want to have at least one of the scopes needed to access the /test path, this is not so good, even on swagger-ui, this is making multiple securityDefinitions for one same authentification rule... For just having multiple scopes for one route.
I know this is maybe not the best solution here, but it can't be cool to think about making the security options more flexible and more readable in case I want one mandatory scope and at least one of the others, something like that is actually not possible with the current specs.
I think it could be better to go with scopes being an array of objects (making the scope checks more granular for one route, can add other rules in it later...)
Don't hesitate to tell me if it's something wrong and why, actually maybe misunderstand something about the whole security specs :)
Thanks for reading
The text was updated successfully, but these errors were encountered:
I need this because my endpoint /test have to be reachable by a user A who own profile:read:birthdate scope only in order to get birthdate but do not need the name. An another user B who own profile:read:name scope only because he can only see the name.
Why i need this? Because i have to implement the concept of RBAC in my code in order to display claims (here birthdate and name) depending of scope owned by the user inside his JWT token.
Note: Example above is simple, but in my case i have a lot of different claims with multiple scopes. I cannot imagine to create a separate endpoint for each claims.
Hello,
I do agree with the above comments.
Just looking to the openid connect default scopes (profile, email, address, phone), not all are necessary when fetching the user information. I guess this behavior is needed in other ReST endpoints.
Regarding the settings, here is another suggestion on how to handle it:
Hello there,
First of all, thanks for your work 馃憤
Context
So, this times I got to add scopes verification and all to different endpoints security (paths).
I want to have multiple scopes for a same securityDefinition to be able to access one route, but I just want to check if the token have at least one of this scopes.
It could be really better if the scopes definition can be an object, with more specifications possibilities, let me explain better.
Current Specs
What we actually have:
With this you must have the scope read and write to access the /test path. To make this scopes optionnals, this should do the trick:
Current Specs Problem
As you can see, this is not the more convenient way to do this, if you want to have at least one of the scopes needed to access the /test path, this is not so good, even on swagger-ui, this is making multiple securityDefinitions for one same authentification rule... For just having multiple scopes for one route.
Specs Refacto Idea
First Idea
So, I think making it something like:
Second Idea
Conclusion
I know this is maybe not the best solution here, but it can't be cool to think about making the security options more flexible and more readable in case I want one mandatory scope and at least one of the others, something like that is actually not possible with the current specs.
I think it could be better to go with scopes being an array of objects (making the scope checks more granular for one route, can add other rules in it later...)
Don't hesitate to tell me if it's something wrong and why, actually maybe misunderstand something about the whole security specs :)
Thanks for reading
The text was updated successfully, but these errors were encountered: