<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="ace-line" id="magicdomid27"><span
class="author-g-q96wvg4vs7mcpr61 b">Hi all<b>,<br>
<br>
</b>Let tried to give you a bit more context.<b><br>
<br>
About Refresh tokens</b></span></div>
<div class="ace-line" id="magicdomid29"><br>
</div>
<div class="ace-line" id="magicdomid2339"><span
class="author-g-q96wvg4vs7mcpr61">This feature is interesting a</span><span
class="author-g-ee35tv1svx6tpo1k">lthough</span><span
class="author-g-q96wvg4vs7mcpr61"> it does not seem mandatory
for our use case for now</span><span
class="author-g-ee35tv1svx6tpo1k">,</span><span
class="author-g-q96wvg4vs7mcpr61"> since clients can already
create tokens with a list of given scopes.</span></div>
<div class="ace-line" id="magicdomid2341"><br>
</div>
<div class="ace-line" id="magicdomid2434"><span
class="author-g-kd9qwnpsinp89fvt">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. </span></div>
<div class="ace-line" id="magicdomid2436"><br>
</div>
<div class="ace-line" id="magicdomid3719"><span
class="author-g-kd9qwnpsinp89fvt">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
</span><span class="author-g-ee35tv1svx6tpo1k">B</span><span
class="author-g-kd9qwnpsinp89fvt">ob to be able to read all
records in the 'music_tracks' collection).</span></div>
<div class="ace-line" id="magicdomid2588"><br>
</div>
<div class="ace-line" id="magicdomid2947"><span
class="author-g-kd9qwnpsinp89fvt">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.</span></div>
<div class="ace-line" id="magicdomid2949"><br>
</div>
<div class="ace-line" id="magicdomid3881"><span
class="author-g-q96wvg4vs7mcpr61">This idea is really handy </span><span
class="author-g-ee35tv1svx6tpo1k">because Alice can just</span><span
class="author-g-q96wvg4vs7mcpr61"> give a </span><span
class="author-g-ee35tv1svx6tpo1k">URI</span><span
class="author-g-q96wvg4vs7mcpr61"> </span><span
class="author-g-ee35tv1svx6tpo1k">(containing the</span><span
class="author-g-q96wvg4vs7mcpr61"> token) to </span><span
class="author-g-ee35tv1svx6tpo1k">B</span><span
class="author-g-q96wvg4vs7mcpr61">ob without </span><span
class="author-g-ee35tv1svx6tpo1k">requiring</span><span
class="author-g-q96wvg4vs7mcpr61"> him to actually </span><span
class="author-g-ee35tv1svx6tpo1k">possess</span><span
class="author-g-q96wvg4vs7mcpr61"> a Firefox Account.</span><span
class="author-g-ee35tv1svx6tpo1k"> On the other hand,</span><span
class="author-g-q96wvg4vs7mcpr61"> </span><span
class="author-g-ee35tv1svx6tpo1k">the main downside is that all
requests will be performed as if Bob were Alice.</span></div>
<div class="ace-line" id="magicdomid3760"><br>
</div>
<div class="ace-line" id="magicdomid4207"><span
class="author-g-ee35tv1svx6tpo1k">A potential solution</span><span
class="author-g-q96wvg4vs7mcpr61"> would </span><span
class="author-g-ee35tv1svx6tpo1k">be to</span><span
class="author-g-q96wvg4vs7mcpr61"> let Alice create tokens</span><span
class="author-g-ee35tv1svx6tpo1k"> (a.k.a keys)</span><span
class="author-g-q96wvg4vs7mcpr61"> </span><span
class="author-g-ee35tv1svx6tpo1k">on our Kinto server</span><span
class="author-g-q96wvg4vs7mcpr61"> and a</span><span
class="author-g-ee35tv1svx6tpo1k">ssign</span><span
class="author-g-q96wvg4vs7mcpr61"> </span><span
class="author-g-ee35tv1svx6tpo1k">permissions</span><span
class="author-g-q96wvg4vs7mcpr61"> </span><span
class="author-g-ee35tv1svx6tpo1k">to</span><span
class="author-g-q96wvg4vs7mcpr61"> th</span><span
class="author-g-ee35tv1svx6tpo1k">e</span><span
class="author-g-q96wvg4vs7mcpr61">s</span><span
class="author-g-ee35tv1svx6tpo1k">e</span><span
class="author-g-q96wvg4vs7mcpr61"> token</span><span
class="author-g-ee35tv1svx6tpo1k">s</span><span
class="author-g-q96wvg4vs7mcpr61"> </span><span
class="author-g-ee35tv1svx6tpo1k">for</span><span
class="author-g-q96wvg4vs7mcpr61"> her collections</span><span
class="author-g-ee35tv1svx6tpo1k">. B</span><span
class="author-g-q96wvg4vs7mcpr61">ob can</span><span
class="author-g-ee35tv1svx6tpo1k"> then</span><span
class="author-g-q96wvg4vs7mcpr61"> use </span><span
class="author-g-ee35tv1svx6tpo1k">it</span><span
class="author-g-q96wvg4vs7mcpr61"> to access Alice's data. Th</span><span
class="author-g-ee35tv1svx6tpo1k">e</span><span
class="author-g-q96wvg4vs7mcpr61">s</span><span
class="author-g-ee35tv1svx6tpo1k">e</span><span
class="author-g-q96wvg4vs7mcpr61"> tokens </span><span
class="author-g-ee35tv1svx6tpo1k">are</span><span
class="author-g-q96wvg4vs7mcpr61"> managed by Alice</span><span
class="author-g-ee35tv1svx6tpo1k"> (revoked when deleted),</span><span
class="author-g-q96wvg4vs7mcpr61"> and she can</span><span
class="author-g-ee35tv1svx6tpo1k"> even decide to</span><span
class="author-g-q96wvg4vs7mcpr61"> create one per person she
wants to share data with.</span></div>
<div class="ace-line" id="magicdomid4357"><br>
</div>
<div class="ace-line" id="magicdomid3763"><br>
</div>
<div class="ace-line" id="magicdomid4493"><span
class="author-g-q96wvg4vs7mcpr61 b"><b>Distinction between
Users, </b></span><span class="author-g-ee35tv1svx6tpo1k b"><b>Groups,</b></span><span
class="author-g-q96wvg4vs7mcpr61 b"><b> Permissions</b></span><span
class="author-g-ee35tv1svx6tpo1k b"><b> and Tokens</b></span></div>
<div class="ace-line" id="magicdomid4689">
<ul class="list-bullet1">
<li><span class="author-g-q96wvg4vs7mcpr61 b"><b>User: </b></span><span
class="author-g-q96wvg4vs7mcpr61">People or App identified
with a unique id</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid6065">
<ul class="list-bullet1">
<li><span class="author-g-q96wvg4vs7mcpr61 b"><b>Group: </b></span><span
class="author-g-q96wvg4vs7mcpr61">Lis</span><span
class="author-g-ee35tv1svx6tpo1k">t</span><span
class="author-g-q96wvg4vs7mcpr61"> of users (note a group
can also be a member of another group)</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid5457">
<ul class="list-bullet1">
<li><span class="author-g-q96wvg4vs7mcpr61 b"><b>Permission: </b></span><span
class="author-g-q96wvg4vs7mcpr61">Read or Write control
towards a</span><span class="author-g-ee35tv1svx6tpo1k">n</span><span
class="author-g-q96wvg4vs7mcpr61"> object</span><span
class="author-g-ee35tv1svx6tpo1k"> (collection, record, ...)</span><span
class="author-g-q96wvg4vs7mcpr61"> for a list of groups or
users</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid5280">
<ul class="list-bullet1">
<li><span class="author-g-q96wvg4vs7mcpr61 b"><b>Token: </b></span><span
class="author-g-q96wvg4vs7mcpr61">Key created by the user
with a subset of </span><span
class="author-g-ee35tv1svx6tpo1k">her</span><span
class="author-g-q96wvg4vs7mcpr61"> permissions that can be
used by application to access data on her behalf. Th</span><span
class="author-g-ee35tv1svx6tpo1k">e</span><span
class="author-g-q96wvg4vs7mcpr61">s</span><span
class="author-g-ee35tv1svx6tpo1k">e</span><span
class="author-g-q96wvg4vs7mcpr61"> tokens can either be
Firefox Accounts Bearer tokens or Anonymous Kinto tokens.</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid4965"><br>
</div>
<div class="ace-line" id="magicdomid5988"><span
class="author-g-q96wvg4vs7mcpr61">We have two things:</span></div>
<div class="ace-line" id="magicdomid5418"><br>
</div>
<div class="ace-line" id="magicdomid5331">
<ul class="list-bullet1">
<li><span class="author-g-q96wvg4vs7mcpr61">permissions given to
a user and stored on the server side</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid6066">
<ul class="list-bullet1">
<li><span class="author-g-q96wvg4vs7mcpr61">permissions </span><span
class="author-g-ee35tv1svx6tpo1k">assigned</span><span
class="author-g-q96wvg4vs7mcpr61"> to a Oauth2 token</span><span
class="author-g-ee35tv1svx6tpo1k"> by its creator</span><span
class="author-g-q96wvg4vs7mcpr61"> a</span><span
class="author-g-ee35tv1svx6tpo1k">nd</span><span
class="author-g-q96wvg4vs7mcpr61"> stored as scopes</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid5985"><br>
</div>
<div class="ace-line" id="magicdomid6157"><span
class="author-g-q96wvg4vs7mcpr61">In the specific case of
anonymous token, the token is </span><span
class="author-g-ee35tv1svx6tpo1k">equivalent to</span><span
class="author-g-q96wvg4vs7mcpr61"> the anonymous user</span><span
class="author-g-ee35tv1svx6tpo1k">, and</span><span
class="author-g-q96wvg4vs7mcpr61"> user's and token's
permissions are the same.</span></div>
<div class="ace-line" id="magicdomid6013"><br>
</div>
<div class="ace-line" id="magicdomid5579"><br>
</div>
<div class="ace-line" id="magicdomid5613"><span
class="author-g-ee35tv1svx6tpo1k b"><b>Relation with FxA scopes</b></span></div>
<div class="ace-line" id="magicdomid5506"><br>
</div>
<div class="ace-line" id="magicdomid5978"><span
class="author-g-q96wvg4vs7mcpr61">For </span><span
class="author-g-ee35tv1svx6tpo1k">FxA</span><span
class="author-g-q96wvg4vs7mcpr61"> and OAuth2 Bearer Tokens we </span><span
class="author-g-ee35tv1svx6tpo1k">thought that it would be
relevant to consider</span><span
class="author-g-q96wvg4vs7mcpr61"> scopes to store the token's
permissions subset.</span></div>
<div class="ace-line" id="magicdomid689"><br>
</div>
<div class="ace-line" id="magicdomid2757"><span
class="author-g-q96wvg4vs7mcpr61">In our generic </span><span
class="author-g-ee35tv1svx6tpo1k">K</span><span
class="author-g-q96wvg4vs7mcpr61">into storage, </span><span
class="author-g-kd9qwnpsinp89fvt">data will be stored</span><span
class="author-g-q96wvg4vs7mcpr61"> for different apps. </span><span
class="author-g-kd9qwnpsinp89fvt">(</span><span
class="author-g-q96wvg4vs7mcpr61">i.e, your readinglist, your
todolist </span><span class="author-g-ee35tv1svx6tpo1k">or</span><span
class="author-g-q96wvg4vs7mcpr61"> your contact</span><span
class="author-g-ee35tv1svx6tpo1k">s</span><span
class="author-g-kd9qwnpsinp89fvt">)</span><span
class="author-g-q96wvg4vs7mcpr61">.</span></div>
<div class="ace-line" id="magicdomid829"><br>
</div>
<div class="ace-line" id="magicdomid2899"><span
class="author-g-q96wvg4vs7mcpr61">T</span><span
class="author-g-kd9qwnpsinp89fvt">he todolist app should not be
able to </span><span class="author-g-ee35tv1svx6tpo1k">read/</span><span
class="author-g-kd9qwnpsinp89fvt">update your contacts, and w</span><span
class="author-g-q96wvg4vs7mcpr61">e th</span><span
class="author-g-ee35tv1svx6tpo1k">erefore</span><span
class="author-g-q96wvg4vs7mcpr61"> need a way</span><span
class="author-g-ee35tv1svx6tpo1k">, on </span><span
class="author-g-q96wvg4vs7mcpr61">the </span><span
class="author-g-ee35tv1svx6tpo1k">K</span><span
class="author-g-q96wvg4vs7mcpr61">into server</span><span
class="author-g-ee35tv1svx6tpo1k">, </span><span
class="author-g-q96wvg4vs7mcpr61">to </span><span
class="author-g-ee35tv1svx6tpo1k">specify</span><span
class="author-g-q96wvg4vs7mcpr61"> </span><span
class="author-g-kd9qwnpsinp89fvt">application permissions on the
data / collections.</span></div>
<div class="ace-line" id="magicdomid1010"><br>
</div>
<div class="ace-line" id="magicdomid5652"><span
class="author-g-ee35tv1svx6tpo1k">Using</span><span
class="author-g-kd9qwnpsinp89fvt"> OAuth2.0 scopes</span><span
class="author-g-ee35tv1svx6tpo1k">, it becomes f</span><span
class="author-g-kd9qwnpsinp89fvt">or instance:</span></div>
<div class="ace-line" id="magicdomid1077"><br>
</div>
<div class="ace-line" id="magicdomid6072"><span
class="author-g-kd9qwnpsinp89fvt">- </span><span
class="author-g-q96wvg4vs7mcpr61">The todolist app will </span><span
class="author-g-ee35tv1svx6tpo1k">request</span><span
class="author-g-q96wvg4vs7mcpr61"> the following scope:
"todolist:tasks:write"</span></div>
<div class="ace-line" id="magicdomid6077"><span
class="author-g-kd9qwnpsinp89fvt">- </span><span
class="author-g-q96wvg4vs7mcpr61">The contact app will </span><span
class="author-g-ee35tv1svx6tpo1k">request</span><span
class="author-g-q96wvg4vs7mcpr61"> the following scopes:
"profile:email,</span><span class="author-g-ee35tv1svx6tpo1k"> </span><span
class="author-g-q96wvg4vs7mcpr61">phonebook:contacts:write"</span></div>
<div class="ace-line" id="magicdomid1263"><br>
</div>
<div class="ace-line" id="magicdomid6080"><span
class="author-g-q96wvg4vs7mcpr61">And if an app </span><span
class="author-g-ee35tv1svx6tpo1k">wants to</span><span
class="author-g-q96wvg4vs7mcpr61"> link todolist tasks with
contacts, </span><span class="author-g-ee35tv1svx6tpo1k">it
should request a</span><span class="author-g-q96wvg4vs7mcpr61">
OAuth2 token with the following scopes:
"todolist:tasks,phonebook:contacts:read" in order to access both
collections.</span></div>
<div class="ace-line" id="magicdomid6081"><br>
</div>
<div class="ace-line" id="magicdomid6158"><span
class="author-g-q96wvg4vs7mcpr61">The formalism to define
permissions as scope could be: </span><span
class="author-g-q96wvg4vs7mcpr61 u"><u>app_id[:collection_id][:record_id]:(read|write)</u></span></div>
<div class="ace-line" id="magicdomid6159"><br>
</div>
<div class="ace-line" id="magicdomid1499"><br>
</div>
<div class="ace-line" id="magicdomid1531"><span
class="author-g-q96wvg4vs7mcpr61 b"><b>About service-to-service
login</b></span></div>
<div class="ace-line" id="magicdomid1533"><br>
</div>
<div class="ace-line" id="magicdomid5739"><span
class="author-g-q96wvg4vs7mcpr61">Our use case</span><span
class="author-g-ee35tv1svx6tpo1k"> could be fulfilled by</span><span
class="author-g-q96wvg4vs7mcpr61"> creat</span><span
class="author-g-ee35tv1svx6tpo1k">ing</span><span
class="author-g-q96wvg4vs7mcpr61"> a token for each service that
let us identify</span><span class="author-g-ee35tv1svx6tpo1k">
it</span><span class="author-g-q96wvg4vs7mcpr61"> </span><span
class="author-g-ee35tv1svx6tpo1k">(uniquely)</span><span
class="author-g-q96wvg4vs7mcpr61"> and then </span><span
class="author-g-ee35tv1svx6tpo1k">assign</span><span
class="author-g-q96wvg4vs7mcpr61"> specific permissions </span><span
class="author-g-ee35tv1svx6tpo1k">for its data</span><span
class="author-g-q96wvg4vs7mcpr61">.</span></div>
<div class="ace-line" id="magicdomid5721"><br>
</div>
<div class="ace-line" id="magicdomid5651"><span
class="author-g-q96wvg4vs7mcpr61">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</span><span
class="author-g-q96wvg4vs7mcpr61 i"><i> <a class="moz-txt-link-abbreviated" href="mailto:paymentapp@mozilla.com">paymentapp@mozilla.com</a> </i></span><span
class="author-g-q96wvg4vs7mcpr61">and then create a Bearer token
that we put in the service configuration to let it access the
service.</span></div>
<div class="ace-line" id="magicdomid2023"><br>
</div>
<div class="ace-line" id="magicdomid2711"><span
class="author-g-q96wvg4vs7mcpr61">A good way to e</span><span
class="author-g-ee35tv1svx6tpo1k">nhance</span><span
class="author-g-q96wvg4vs7mcpr61"> the 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.</span></div>
<div class="ace-line" id="magicdomid2026"><br>
</div>
<br>
Best regards,<br>
<br>
Alexis, Mathieu and Rémy<br>
<br>
<br>
<div class="moz-cite-prefix">Le 07/05/2015 03:18, Ryan Kelly a
écrit :<br>
</div>
<blockquote cite="mid:554ABD72.5080503@mozilla.com" type="cite">
<pre wrap="">
(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:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
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?
</pre>
<blockquote type="cite">
<pre wrap="">Service to service auth
==============
There are open issues about this [1] and I believe Ryan is working on this?
[1] <a class="moz-txt-link-freetext" href="https://github.com/mozilla/fxa-oauth-server/issues/125">https://github.com/mozilla/fxa-oauth-server/issues/125</a>
</pre>
</blockquote>
<pre wrap="">
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:
<a class="moz-txt-link-freetext" href="https://github.com/mozilla/fxa-oauth-server/blob/master/docs/api.md#post-v1authorization">https://github.com/mozilla/fxa-oauth-server/blob/master/docs/api.md#post-v1authorization</a>
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
</pre>
</blockquote>
<br>
</body>
</html>