Hi Ryan, You are raising good questions here.
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:
* Firefox for Android Font updates (To authenticate the script that
can make the update)
* AMO Blocklist updates (To authenticate the updater service that can
update and sign the blocklist.)
* OneCRL updates. (To authenticate the updater service that can update
and sign the CRL.)
Maybe, the scopes could be passed on the Bearer Token requests.
I mostly sent this email because I though about it while reading the
Twitter API documentation.
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.
Best regards,
Rémy
Le 30/11/2015 00:08, Ryan Kelly a écrit :
> On 29/11/2015 21:12, Rémy Hubscher wrote:
>> 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.
> 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 https://oauth.accounts.firefox.com/v1/verify
> <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
>
>
>> 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]
>> http://kinto.readthedocs.org/en/latest/tutorials/permission-setups.html
>>
>> Le 28/11/2015 21:53, Sean McArthur a écrit :
>>> 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
>>> <<mailto:[email protected]>[email protected]> wrote:
>>>
>>> Hello,
>>>
>>> While reading the Twitter documentation, I realized they have an
>>> Application-Only authentication mechanism
>>> <https://dev.twitter.com/oauth/application-only> 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 [email protected]
>>> <mailto:[email protected]>
>>> https://mail.mozilla.org/listinfo/dev-fxacct
>>>
>>
>>
>> _______________________________________________ Dev-fxacct mailing
>> list [email protected]
>> https://mail.mozilla.org/listinfo/dev-fxacct
>>
> _______________________________________________
> Dev-fxacct mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/dev-fxacct
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
