<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Ryan,<br>
<br>
You are raising good questions here.<br>
<br>
Most use-cases that we are using with Kinto right know could benefit
from this feature but we can continue to use BasicAuth for that:<br>
<ul>
<li>Firefox for Android Font updates (To authenticate the script
that can make the update)<br>
</li>
<li>AMO Blocklist updates (To authenticate the updater service
that can update and sign the blocklist.)<br>
</li>
<li>OneCRL updates. (To authenticate the updater service that can
update and sign the CRL.)</li>
</ul>
Maybe, the scopes could be passed on the Bearer Token requests.<br>
<br>
I mostly sent this email because I though about it while reading the
Twitter API documentation.<br>
I think there are no hurry to implement that as far as I know, but
as soon as it is available, we will probably want to switch from
BasicAuth to Service side application Bearer Tokens.<br>
<br>
Best regards,<br>
<br>
Rémy<br>
<br>
<div class="moz-cite-prefix">Le 30/11/2015 00:08, Ryan Kelly a
écrit :<br>
</div>
<blockquote cite="mid:565B8557.1020102@mozilla.com" type="cite">
<pre wrap="">On 29/11/2015 21:12, Rémy Hubscher wrote:
</pre>
<blockquote type="cite">
<pre wrap="">The use case I have in mind would be to give specific permissions
to an application while using Kinto [0].
Currently we are using BasicAuth directly for that task:
* giving the permission to the payment app to write receipts for a
user and a seller app, * then giving the permission to the seller
app to read all its receipts.
</pre>
</blockquote>
<pre wrap="">
So the proposal would be, that these apps generate tokens that
identify them as acting on behalf of the app itself rather than any
particular user. When kinto verifies the token is would see something
like:
POST <a class="moz-txt-link-freetext" href="https://oauth.accounts.firefox.com/v1/verify">https://oauth.accounts.firefox.com/v1/verify</a>
<client-specific token here>
{
"user": null,
"client_id": "<payments app client id>"
"scope": []
}
And can check the "client_id" and allow or deny operations accordingly?
I think it makes sense to try to centralize app-credential-management
inside FxA where we're doing it already, but the data model here would
require some careful thought. For example, what scopes would be valid
in such a token and what would they mean?
We'd also have to carefully weigh the priority of this feature w.r.t.
all the other things we could be implementing. IIUC payments is a bit
on the backburner for now, do you have another concrete use-case in mind?
Cheers,
Ryan
</pre>
<blockquote type="cite">
<pre wrap="">Using a Firefox Account Bearer token instead would prevent us for
leaking the app credentials to the server (even if it is protected
bya SSL connection) but also let us revoke a token and create a new
one in case we need to (ie it has been compromised).
Changing the BasicAuth credentials also change the userid which
prevent us from changing them easily.
[0]
<a class="moz-txt-link-freetext" href="http://kinto.readthedocs.org/en/latest/tutorials/permission-setups.html">http://kinto.readthedocs.org/en/latest/tutorials/permission-setups.html</a>
Le 28/11/2015 21:53, Sean McArthur a écrit :
</pre>
<blockquote type="cite">
<pre wrap="">
That looks simple enough. It seems Twitter uses this to increase
rates limits if an application identifies itself (instead of a
lower limit based on IP). It doesn't provide access to any
private information, or allow the application to act as a user.
What would be the desired effect for FxA? We don't really have
public APIs... Accessing a user's private information will
require getting their permission.
We do have Service Accounts, which allow access to all
information without user action, but they require explicit
registration with us, such as our use of Basket.
On Sat, Nov 28, 2015, 12:37 AM Rémy Hubscher
<<a class="moz-txt-link-rfc2396E" href="mailto:rhubscher@mozilla.com"><mailto:rhubscher@mozilla.com></a><a class="moz-txt-link-abbreviated" href="mailto:rhubscher@mozilla.com">rhubscher@mozilla.com</a>> wrote:
Hello,
While reading the Twitter documentation, I realized they have an
Application-Only authentication mechanism
<a class="moz-txt-link-rfc2396E" href="https://dev.twitter.com/oauth/application-only"><https://dev.twitter.com/oauth/application-only></a> that is quite
easy.
They are using client_id and client_secret in a BasicAuth
fashion in order to get a BearerToken on this URL /oauth2/token
This could be a quite easy solution to implement I guess while
reusing the current ecosystem we have.
Best regards,
Rémy _______________________________________________ Dev-fxacct
mailing list <a class="moz-txt-link-abbreviated" href="mailto:Dev-fxacct@mozilla.org">Dev-fxacct@mozilla.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:Dev-fxacct@mozilla.org"><mailto:Dev-fxacct@mozilla.org></a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/dev-fxacct">https://mail.mozilla.org/listinfo/dev-fxacct</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________ Dev-fxacct mailing
list <a class="moz-txt-link-abbreviated" href="mailto:Dev-fxacct@mozilla.org">Dev-fxacct@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/dev-fxacct">https://mail.mozilla.org/listinfo/dev-fxacct</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Dev-fxacct mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dev-fxacct@mozilla.org">Dev-fxacct@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/dev-fxacct">https://mail.mozilla.org/listinfo/dev-fxacct</a>
</pre>
</blockquote>
<br>
</body>
</html>