Using OAuth 2 scopes in access tokens

[Alan Karp]

https://auth0.com/blog/on-the-nature-of-oauth2-scopes/

The tl;dr is that generating fine-grained permissions, e.g., separate read and write permissions for each file, generates too much load on the issuer of capabilities, and it is impractical to keep the policy the issuer uses up to date in a highly dynamic environment.

I believe that what the author is saying applies to essentially all capability systems.  I have my own comments on these problems, but I'd like to hear yours.

--------------
Alan Karp

[Terry Hayes]

Thanks Alan,

I got as far as the example with "me/messages", "users/guid/messages" and the Mail.Read scope.  The author then states:

The true resources in this example are really the inboxes of each user, and that was carried by the REST call rather than the token used to secure it… and the authorization decision emerged from combining the scope Mail.Read (without which we wouldn’t have bothered doing anything else), the identifier of the user (carried through a different claim in the token) and the entity requested (in the URL of the entity, hence in the actual call).

Exactly!  The designation and the authorization have been separated, a classic no-no in capability systems.  Once that happens, it is very difficult to reason about, or even correctly implement the system.  In this particular case, any inbox that the "User" can read "Mail.Read" is available, even though only one inbox was intended in the original token request.

Terry

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z0PMW5BCTxi8Eakjia6%2BjP%3Ds8MwN%3D3WKLsqM1wtJJMVbQ%40mail.gmail.com.

[Alan Karp]

The fundamental flaw here was making the resource MAIL.READ instead of /user/guid/messages, a kind of mistake that is common in that community.

--------------
Alan Karp

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAGLSb_Vp4xxPdeine6fdxVE83w%2BcXV2RV01EWMHMuUgduJ1fyw%40mail.gmail.com.

[William ML Leslie]

To the argument about "omniscient" policy servers; the reverse is true: you no longer need a separate system to maintain access policy, as each server must merely understand how to check its own resources for validity.