On 8/05/2015 00:18, Rémy Hubscher wrote:
>
> About Refresh tokens*
>
> This feature is interesting althoughit does not seem mandatory for our
> use case for now,since clients can already create tokens with a list of
> given scopes.
>
> That being said, I think it's interesting to discuss that while it's
> fresh and in implementation, so we can spot if it fits our use cases,
> needs to be improved or is something we can use as-is.
>
> So, the idea behind the use of refresh tokens for sharing is that we
> need to have a way for Alice to share a set of permissions with someone
> else (She wants Bob to be able to read all records in the 'music_tracks'
> collection).
>
> What we had in mind is to use bearer tokens with a defined scope which
> reflects the permission Alice granted to Bob, so he can access Alice
> shared records.
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?
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.
> *Distinction between Users, **Groups,**Permissions**and Tokens*
>
> * *User: *People or App identified with a unique id
>
> * *Group: *Listof users (note a group can also be a member of another
> group)
What are these groups for, and who manages the list of members of a group?
> * *Permission: *Read or Write control towards anobject(collection,
> record, ...)for a list of groups or users
>
> * *Token: *Key created by the user with a subset of herpermissions
> that can be used by application to access data on her behalf.
> Thesetokens can either be Firefox Accounts Bearer tokens or
> Anonymous Kinto tokens.
>
> We have two things:
>
> * permissions given to a user and stored on the server side
>
> * permissions assignedto a Oauth2 tokenby its creatorandstored as scopes
>
> In the specific case of anonymous token, the token is equivalent tothe
> anonymous user, anduser's and token's permissions are the same.
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.
> *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.
> *About service-to-service login*
>
> Our use casecould be fulfilled bycreatinga token for each service that
> let us identifyit(uniquely)and then assignspecific permissions for its data.
>
> A simple hack to let us do what we want could be to create a Firefox
> Account user for our service with a service email
> like/[email protected] /and then create a Bearer token that we put
> in the service configuration to let it access the service.
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.
It seems to me that we can do all of the above points without needing
the "only certain clients can get certain scopes" thing that you
mentioned in a previous email. Am I missing something?
Cheers,
Ryan
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
