Hi all*,
*Let tried to give you a bit more context.*
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 idea is really handy because Alice can justgive a URI(containing
thetoken) to Bob without requiringhim to actually possessa Firefox
Account.On the other hand,the main downside is that all requests will be
performed as if Bob were Alice.
A potential solutionwould be tolet Alice create tokens(a.k.a keys)on our
Kinto serverand assignpermissionstothesetokensforher collections. Bob
canthenuse itto access Alice's data. Thesetokens aremanaged by
Alice(revoked when deleted),and she caneven decide tocreate one per
person she wants to share data with.
*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)
* *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.
*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)_
*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.
A good way to enhancethe process would be to let Firefox Account user to
create personal token to delegate some rights to some app, but it is
really close to what we can do with today's Bearer Token.
Best regards,
Alexis, Mathieu and Rémy
Le 07/05/2015 03:18, Ryan Kelly a écrit :
> (Redirecting to dev-fxacct since I really want to encourage more
> discussion on the list.)
>
> On 5/05/2015 23:46, Alexis Métaireau wrote:
>> About scopes
>> ========
>>
>> The FxA team is adding the concepts of "Refresh Tokens" [0] to the FxA
>> OAuth server.
>>
>> The current behavior is:
>> - The user asks for an OAuth bearer token with a list of scopes;
>> - It is given this bearer token and uses it to authenticate against
>> services;
>> - Services get the token with scopes that aren't needed, and a malicious
>> service could use the token to impersonate an user (for instance).
>>
>> The planned future behavior is:
>>
>> - The user asks for an OAuth *refresh* token to the OAuth server;
>> - When she wants to authenticate to a service, the user asks the OAuth
>> server to trade its refresh token for a bearer token (with a narrower
>> list of scopes and duration)
>> - It would be possible to trade a refresh token for a token with a
>> longer duration (infinite?) and a specified scope. I was thinking about
>> using this as a "share this information with anyone" if we handle
>> permissions trough scopes.
> To be clear, this last capability is not currently on our roadmap for
> FxA. We should have a conversation about the requirements here and try
> to come up with a plan.
>
>> Just to try to formulate Rémy question in a different way: *Is it
>> possible to have scopes attached to a specific client id? *I know that
>> currently when we generate a clientid/secret we grant all scopes, but is
>> there a way to do this differently?
> To be sure I understand the question, do you mean: can we have certain
> scopes that are only ever granted to specific client_ids?
>
> For example, a "payments" scope that can only ever be granted to the
> official "payments" service?
>
> 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.
>
> Note that tokens are tied to the client_id that generated them. Given a
> token, you can always tell which client_id "owns" it.
>
> 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?
>
>
>> Service to service auth
>> ==============
>>
>> There are open issues about this [1] and I believe Ryan is working on this?
>>
>> [1] https://github.com/mozilla/fxa-oauth-server/issues/125
> We are working on this, but it will be great to flesh out some more
> concrete use-cases.
>
> The flow here would be broadly similar to our existing direct-grant flow
> using response_type=token here:
>
>
> https://github.com/mozilla/fxa-oauth-server/blob/master/docs/api.md#post-v1authorization
>
> But instead of passing an FxA identity assertion to say "I'm acting on
> behalf of this user", you would pass a JWT or some other token to say
> "I'm acting on behalf of this service".
>
> Details TBD, would love your team's help in finalizing out how this flow
> should work.
>
> It probably makes sense to stub in your own service-to-service auth in
> the meantime, so that you don't block on us having this ready.
>
>
> Cheers,
>
> Ryan
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
