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
