On 26/11/2015 08:09, Jared Kerim wrote: > I am implementing a web application for cloud services called the > Mozilla Geolocation Service Leaderboard, which will utilize FXA for user > accounts. > > https://github.com/mozilla-services/location-leaderboard
Cool. By the way, if you haven't seen it, there's a python client library for FxA that you might like to contribute to if you find yourself hand-rolling too much code for the oauth flow: https://github.com/mozilla/PyFxA > My original plan was to store the FXA access token and the FXA UID in > the database, as well as pass both of those to the client. When the > client wants to make an API call, it will provide the UID as a way to > identify itself and the access token to authorize the call. > > I was going to store both in the database, but I think that I don't need > to store the access token at all, it can be stored only in the client, > passed to the server through an Authorization header during a request, > relayed to FXA for validation, and the call is considered authorized. This sounds good to me, but be careful, because the "relayed to FxA for validation" step has a lot of nuance. How will you know that it's a bearer token for the leaderboard app, rather than e.g. a token I got by logging into pocket? Two options: * The verification call [1] returns the client_id that owns the token, so you can check that it's your app's client id and reject if not. * Require the token to have a specific scope, e.g. "stumbler", and check for that scope in the response from [1]. The second option would be more in the spirit of OAuth, but maybe slightly more work for your API. I'd also encourage you to request a refresh token, pass both refresh_token and access_token back to your client, and have it use the refresh_token for ongoing access to the API; see "access_type=offline" at [2]. [1] https://github.com/mozilla/fxa-oauth-server/blob/master/docs/api.md#post-v1verify [2] https://github.com/mozilla/fxa-oauth-server/blob/master/docs/api.md#request-parameters-5 > In this case I only need to store the FXA UID. > > However, if I only use the FXA UID as a way to identify a user, then > that is the parameter that will appear in all API calls to identify > users, which means this FXA UID will be publicly available. > > In his security review, Julien had suggested that the FXA UID should > remain 'restricted' to within the server database and not exposed > through the API. When we discussed this over Vidyo I think I didn't quite catch a key point, so to clarify: in this proposal, would my FxA uid be exposed to other users of the system? Knowing another user's FxA uid doesn't give you any power over their account, but it might have some privacy/tracking implications. OpenID Connect actually has a bit to say about this topic, and suggests the use of "Pairwise Pseudonymous Identifiers" (PPI) so that the FxA uid seen by the leaderboard app cannot be correlated to e.g. the FxA uid as seen by Pocket. But we don't implement that yet, and we don't have concrete plans on whether or when we would. [3] http://openid.net/specs/openid-connect-messages-1_0-20.html#Correlation > If this is the case, then I will need to create a UID which is local to > just the leaderboard, and store both the leaderboard UID and the FXA UID > on my user table to correlate the two. This is possible but perhaps > more work than is necessary, particularly because I will need to 1) > receive the access token from the client 2) validate it with FXA and 3) > receive a payload from FXA which includes the FXA UID and then use that > to identify the user in my local database table. If we decide this is necessary, it may make sense to try to implement a simple PPI scheme once inside FxA, rather than encouraging every new connected service to roll their own version of it. > Is it necessary to store both a local UID and an FXA UID in my database, > or is it reasonable to use only the FXA UID to identify a user? I'd love to hear others' takes on the subject. Thoughts? Cheers, Ryan _______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
