On 08/05/2015 00:46, Ryan Kelly wrote:
This seems OK at first glance. I'm not sure if there's prior art in the
OAuth ecosystem for this. If I understand correctly it's similar to the
notion of "bewit" tokens in Hawk, right?
Yes, it's a similar concept. However, bewit are limited to GET and are
limited in time [0], which is something that would be too limitant for
our use case. The hawk documentation states there are security risks in
doing so, so we might want to be careful here.
I don't think you necessarily need refresh tokens for this, so much as a
scope-narrowing endpoint of some sort. For example, if you have a
refresh token with scope "music+payments" then there are two things you
might like to do with it:
1) Create short-lived access tokens for talking to the music service
2) Create another long-lived refresh token with just "music" scope,
which you can then give to Bob for delegating access.
I don't see in the OAuth 2.0 spec a way to exchange a refresh token for
another refresh token, and that's why I was proposing to use an *access*
token with a longer life, but having a way to get another refresh token
also seems something we might want to do. It means more work for the
clients, though, since they'll need to trade this refresh token for an
access token.
Also, it seems that this "delegation of authorization" approach also
means "delegation of authentication", which might be something we don't
want. For instance, if Alice delegates access to Bob, then Bob actually
authenticate as Alice. We might have a way to know this is not Alice,
but we need to be careful with this.
What are these groups for, and who manages the list of members of a group?
We thoughts of groups as a way to easily share to a number of persons.
In the Storage server, as we need a way to handle permissions, it's
sometimes easier to give access to a group, and then add users to this
group.
Who handles these groups, how, and what are their scopes is another
interesting beast :) Not to be too long on this, but we were thinking,
for the storage, about storing groups in collection (or buckets, but
this is something we're still fleshing out).
I believe we should discuss that on the github issue [1] rather than
here since it's a bit off-topic.
Hmmm, OK, so it sounds like you're layering on extra permissions and
security management from within the service in a generic way.
IMHO this argues in favour of managing your own auth tokens rather than
trying to use FxA OAuth tokens for all requests.
That's a fair point. Also, I think this is a generic problem different
services will try to address and we should try to make this simple for
them when it happens.
*Relation with FxA scopes*
For FxAand OAuth2 Bearer Tokens we thought that it would be relevant to
considerscopes to store the token's permissions subset.
In our generic Kinto storage, data will be storedfor different apps.
(i.e, your readinglist, your todolist oryour contacts).
The todolist app should not be able to read/update your contacts, and we
thereforeneed a way, on the Kinto server, to specifyapplication
permissions on the data / collections.
UsingOAuth2.0 scopes, it becomes for instance:
- The todolist app will requestthe following scope: "todolist:tasks:write"
- The contact app will requestthe following scopes:
"profile:email,phonebook:contacts:write"
And if an app wants tolink todolist tasks with contacts, it should
request aOAuth2 token with the following scopes:
"todolist:tasks,phonebook:contacts:read" in order to access both
collections.
The formalism to define permissions as scope could be:
_app_id[:collection_id][:record_id]:(read|write)_
This seems good so far, although that's potentially a lot of scopes. At
some point we'll need to consider how to present these scopes to the
user for confirmation, with nice meaningful descriptions and in
different languages.
We've talked about whether the fxa-oauth-server needs to centrally
manage the canonical list of scopes:
https://github.com/mozilla/fxa-oauth-server/issues/143
But haven't moved on it yet, because we haven't needed to. Something to
think about though.
Oh okay, gotcha. It's kindo of hard to grasp since it means the storage
server would either handle multiple scopes (payments, readinglist) or
introduce another level of scopes (storage:payments, storage:readinglist).
In either case, we need a way to register these scopes in the OAuth
server somehow and display them to the users. Having a placeholder in
the description would make sense in terms of l10n, and then users would
be asked to "authorize access for {collection} storage".
note to Natim & Mat, we also need to think this further with the notion
of buckets we discussed last week.
Let's not do that hack :-)
If the payments app is an FxA service provider of its own, then I think
this notion of service-to-service tokens will work OK. The payments app
could get a token that says "I'm client XYZ, and I'm acting on behalf of
myself" and you could check against the client-id in the token as part
of your security model.
How you know that "client_id: XYZ" is actually the payments app is an
open question. You could just maintain a map of known client ids. Or
perhaps we could consider identifying them by domain name rather than an
opaque hex id.
+1 for not doing this.
That's where I thought scopes would be helpful again, but apparently I'm
wrong with this. That's why I was asking in a previous mail if it was
possible to have a client id tailored to specific scopes.
so, if I understand correctly, that's not how scopes are working: An
client asks the user access to a scope and *the user* gives access to
the scopes. I was thinking it was possible to limit the number of scopes
a user could grand, depending on the client id.
That being said, it seems possible to map client ids with acess levels,
so we should be okay (e.g. if a requests comes in, once the validity of
the token verified, we only give access if this token was issued by [one
of] the client id of the payment app)
Cheers,
— Alex
[0] https://github.com/hueniverse/hawk#single-uri-authorization
[1] https://github.com/mozilla-services/kinto/pull/36
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
