[anderspitman]

Thanks for the link. I'm rolling my own for a reason. I'm working on not only an Oauth2 implementation, but also a specification for using Oauth2 for filesystem operations (btw if you're aware of such a thing existing already, I'd love to hear about it). So I need to be intimately familiar with Oauth2. I wasn't originally planning to use it, but ultimately it's close enough to what I need, and for better or worse users are familiar with the flows.

[dwaite]

> btw if you're aware of such a thing existing already, I'd love to hear about it

Since OAuth is pretty coarse-grained, you tend to have: - A client has a policy configured for the file sharing service or file collection, and does not use e.g. the scope parameter to request particular permissions - A file collection lets scopes be assigned particular permissions, and a client requests access by requesting one or more scopes

Although I am not a fan of the level of complexity it adds, UMA (User Managed Access) makes a pretty strong attempt at solving these sorts of problems as well.

[anderspitman]

But why do they have to be coarse-grained? If you have a cloud storage provider, why not allow scopes to be set per path, like this:

scope="/dir1:read /dir2:write /dir3/file.txt:read"

Then when the authorization screen is presented, the user could even modify the permissions granted on the fly.

Usually applications only need a single directory to store data, and it shouldn't matter to the app where that directory is in relation to the rest of the user's data. In that case you could do something like this:

scope="dir?:write"

Which tells the authorization server to present the user with a directory picker, so the user has control over where the data is stored. It doesn't make any sense to give write permissions to all your data for every single application.

After 5 minutes of poking around, I still don't understand how exactly UMA works in relation to Oauth2. I agree it seems to be pretty complex.