What do you think about using scoping as an authorization action?

[factyy]

The idea is simple: Action Policy supports scoping (which we gladly use with our Graphiti integration), but don't you think that:

1. When we are authorizing an index action, we will most likely rely only on requesting users's fields. If we take scoping into account (e.g. user is prohibited from listing entities) we can effectively fold his scope into an empty collection thus preventing him from using index action at all (we think that it is not a big deal to return HTTP 200 with an empty collection instead of HTTP 401);
2. When we are authorizing a show action, we can rely on scoping again (since it is not so different from an index action);
3. And then we have the verify_authorized marker. If we only use scoping for index and show authorization, we'll end up with an authorization error in the end.

The idea is simple: is it a suitable use case to treat index and show actions as authorized (passing verify_authorized checks) if the scoping was successfully performed?

P.S. the idea was born simply because with our Graphiti integration it is much harder to try to authorize index actions (we moved the authorization to resources (model proxies) from controllers since you can side-post multiple entities in the same request with JSON:API breaking the 1-to-1 relationship between a controller, a model and a policy).

Edit: fix a typo

[ezekg]

I'll preface this with the fact that I don't have experience with GraphQL or Graphiti. So this will be my generalized approach to authz.

Personally, I wouldn't rely solely on scoping for authz, simply because your scope may have a bug in the future that leaks records. It may not now, but it could. When it comes to authz, I like to be as defensive as possible. It's better to catch that and send a 401 than to render records you shouldn't. The controller should scope the models, and the policy should assert that scope. It's safer to have both of those assertions than to only have one. So I typically do both. With eager loading, N+1s aren't a concern.

[factyy]

Yeah, it makes sense. Good argument to consider, thanks!

[factyy]

@palkan , it will really help us if you share your thoughts on the subject as an original author :)

[palkan]

Thanks for the question!

Scoping-based authorization is a common technique, but I would use it with caution. Especially the following scenario:

When we are authorizing a show action, we can rely on scoping again

Yes, we can. From the first look, having @record = authorized_scope(Record.all).find(params[:id]) is similar to authorize! (@record = Record.find(params[:id])), so why having both scoping rules and singleton rules? However, from my experience, using scopes as a single source of truth tend to result in poor performance: a complex scope query can be very inefficient compared to a simple primary key lookup and pure Ruby authz check.

So, I prefer to separate single-record checks from scopes. What would be great is to link rules and scopes, i.e., have a built-in mechanism which verifies that scopes and checks are in sync (i.e., if record.in?(authorized_scope(Record.all)) then authorize! record, to: :show? must pass).

[factyy]

Well, it makes total sense

Thank you!

[factyy]

Thanks everyone for your ideas!