On 12/05/2015 08:03, Alexis Métaireau wrote: > Okay, > > After having put some more thoughts in, it seems that we need to > use OAuth2.0 scopes, but not as a traditional way to define > permissions for the users.
Details inline, but at a high level: I agree with and support pretty much everything you say below, and feel like what you describe is a quite traditional and standard use of OAuth2.0 scopes. So perhaps I just misunderstood what you were getting at in previous emails; apologies if so. > Taking back the example Rémy took in an earlier thread: > > Consider two collections for a given user, Bob: "Tasks" and > "Contacts". And then two applications, which need different > accesses rights: > > - "Address Book", which need `read+write` permission on the > "Contacts" collection; - "Todo List", which needs `read` permission > on "Contacts" and `read+write` permission on "Tasks". > > All this data belongs to Bob, but he wants to have different > applications access his data with different rights. That's where > scopes come into play. Even if Bob has all read+write rights on > both collections, he wants to give the apps only a subset of > these. In our example, he would give "address book" the > "tasks:read+write" and "contacs:read" scopes, even if he, as a user > has access to everything. It might not be easy to get when looking > at user data (where the user has all the rights) but there are > indeed two levels of authorization here: Bob should have access AND > the application should have access. Yep, all of the above sounds excellent and is exactly what scopes are designed for. > With that in mind, let's take back Ryan previous remarks: > >> This seems to go against the grain of OAuth, where scopes and >> reliers are orthogonal concerns. I think of client_id as "who >> you are" and the scopes as "what you can do" and it doesn't seem >> like a good idea to conflate them. > > Here, scopes and reliers aren't really orhogonal concerns, of > course, since the scopes are defined for the reliers. There are three parties here: the user, the relier, and the service. The set of possible valid scopes is defined by the service, in this case the storage service. It will honour the scopes that it knows about (such as "contacts:read") and it will ignore scopes for things that it doesn't provide (such as "profile:email"). The user cant grant scopes to a particular relier via the OAuth dance, to allow that relier to access the service on their behalf. But the service will recognize the same fixed set of scopes, regardless of how many reliers are accessing it. That's what I mean by "orthogonal" in this context. In a previous email, there was suggestion that e.g. the payments relier could have a special "paymentsapp" scope that nobody else is allowed to request. This was the part that didn't seem right to me. The scopes should be "things that someone can do" and the reliers are "entities who can do things" and they should be two independent sets. > The client_id defines who "the app" is, and I would expect to have > some way to say "this app should only access these scopes". This I absolutely support. In fact we've made a first small step towards this by restricting the set of scopes that can be requested by non-Mozilla reliers: https://github.com/mozilla/fxa-oauth-server/commit/8fd228ad5f77492b3b9341928ec1db6547161bfb I can imagine us adding similar restrictions on a case-by-case basis, e.g. you might have to go through some sort of verification process before we allow your app to request the "payments" scope. > I remember seing this with the Twitter API when registering an > application, where they were asking me which scopes I should be > able to ask. Cool. Yes, we should definitely do this as developer footgun protection. But I assume that you signing up as a twitter relier didn't create a new privileged "alexis" scope that only your app can access, and you as a relier didn't have the opportunity to create new scopes. >> Note that tokens are tied to the client_id that generated them. >> Given a token, you can always tell which client_id "owns" it. > > That would work for a non-generic storage, but here, for a generic > storage, it's kind of tricky since we don't know what the clients > ids will be and what they should do at the begining (and new ones > should be able to be created). This bit I don't understand sorry - what effect does a new client_id coming online have on the scopes offered by the storage service? > I believe what I want is a way to protect our users against > themselves, e.g. them clicking "yes, I want to grant this scope for > this app" even if they don't understand the implications. Maybe we > should do that and we should let the user make informed choices, > but I'm pretty sure they'll do the wrong thing in a good portion of > cases. Or, and that's something we should think about carefully, > these scopes should be shown to the user in a clever way, so they > exactly know what they do and the can make an informed decision. I broadly agree here - there's a lot we can do, and should do, to protect users from click-through accidents and to prevent developers from accidentally or maliciously requested unexpected scopes. >> Let's dive deeper into the requirements driving this question, I >> suspect we can come up with something cleaner. What do you want >> to achieve by restricting scopes in this way? > > I believe I formulated and answer to that already, if not, please > tell me and I'll be happy to do it differently! Thanks Alexis, I feel like I understand things a lot better now! All of the above seems to be about Bob delegating authority that he already has. For example, Bob has the ability to "contacts:read" so he is able to pass that authority over to a third party via the OAuth dance. How do you see this working for payments, where we want to grant the payments backend app a capability that Bob does not have? (Namely, the ability to write new payment receipts into the store). Do we create a scope like "payments:write" that Bob himself is not allowed to have, but that the payment app can grant to itself via some backend token dance? Cheers, Ryan _______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
