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