(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
