Skip to content
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

Separate authorization (403) from authentication (401) #3633

csrl opened this issue Oct 22, 2017 · 1 comment

Separate authorization (403) from authentication (401) #3633

csrl opened this issue Oct 22, 2017 · 1 comment
feature New functionality or improvement


Copy link

csrl commented Oct 22, 2017

outmoded/discuss#407, outmoded/discuss#341 and #3425 touch on the need for matching 'scope' against more than just param and query values.

#3425 was closed, I believe because it asked for enhanced pattern matching of the scope string, which was not of interest, but the issue does capture much of the discussion around this topic.

Its a pretty trivial, and I suspect common use case - the need to indirectly map a request to an authorization scope.

I think we either need to be able to dynamically modify the route's scope for the request's duration, or be able to populate a set of variables that can be templatized in the scope rule for the route. Probably the latter is preferable.

To achieve that, what I'm asking for here is to remove the scope checking (ie. checking access rules in auth) from the authentication stage and move it to an authorization step either to after 'Payload validation' in the lifecycle, or to before 'Route handler' in the lifecycle.

The primary need I'm seeing from the existing requests, align with my own, and comes from a user having a scope for, lets say, a 'group-{groupId}', but a route input doesn't explicitly include the {groupId}, but the groupId must be looked up indirectly (from a database) based on something else in the request, perhaps an {itemId} or whatever. As there may be thousands of itemIds, it is not ideal to have to look them all up based on the user's groupIds during authentication in order to add each itemId to the authenticated credentials scope.

The proposed authorization point could provide a method function, in which it is possible to modify the route scope only for the current request or to populate the template variables used in the scope rule template.

However, typically looking up the 'groupId' object from the current request would already be done in a pre-handler, so making the authorization step follow the pre-handlers instead makes some sense, but I can also see potential conflict, depending on how people have implemented. Although, in a significant way, I think separating pre-handlers from the route handler with an authorization step would greatly improve (but change) the meaning and purpose of pre-handlers.

Thanks for reading. I'd been wanting to use the native scope support for some time for authorization, but this is a significant limitation. It seems others are running into it as well.

@hueniverse hueniverse self-assigned this Oct 22, 2017
@hueniverse hueniverse added breaking changes Change that can breaking existing code feature New functionality or improvement labels Oct 22, 2017
@hueniverse hueniverse added this to the 17.0.0 milestone Oct 22, 2017
@hueniverse hueniverse changed the title separate authorization (403) from authentication (401) Separate authorization (403) from authentication (401) Oct 22, 2017
@hueniverse hueniverse added request and removed breaking changes Change that can breaking existing code feature New functionality or improvement labels Oct 22, 2017
Copy link

I am going to do something else - a way to change the request credentials in between authentication and payload and access rules validation. The route rules are static, but you will be able to set the scope after the request is authenticated and payload is fully parsed.

@Marsup Marsup added feature New functionality or improvement and removed request labels Sep 20, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Mar 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
feature New functionality or improvement
None yet

No branches or pull requests

3 participants