> Knowing another user's FxA uid doesn't give you any power over their account, but it might have some privacy/tracking implications.
Yes, exactly. It could be possible to identify the user over other properties, which is bad for privacy. I like the suggestion of solving this in OpenID Connect. We can easily provide a per-client id, doing `sha256(client_id + uid)`. On Wed, Nov 25, 2015 at 8:05 PM Ryan Kelly <[email protected]> wrote: > 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 >
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
