1225620 - Need prod FxA client ID & secret for Geolocation Leaderboard

Status: NEW

(Cloud Services :: Operations: Miscellaneous, task)

Description

[Jared Kerim [:jkerim]]

Geolocation Leaderboard needs a client ID & secret production Firefox Accounts. 

Name: 
Mozilla Location Service Leaderboard

Redirect URL:
https://<production domain not yet determined>/api/v1/fxa/redirect/

Dev Client ID: 
8068585724a0bc0a

Dev/Stage/Prod Data Sharing:
Not necessary, each deployment may have its own isolated data set, it's not necessary to share.

No redirectUri behaviour necessary, the callback handler is the final destination of an Oauth flow.

Thanks!

Comment 1

[Jared Kerim [:jkerim]]

* Can users sign in to the leaderboard website with FxA, or just only sign in via the UI in the android client?

Eventually yes, that is the plan.  That functionality is not implemented or required for our initial production launch.

 * I assume the client will be using the java library that :vng was working on.  Do you know whether the client-id needs to be marked as an "implicit grant client" in order to work correctly with this codebase?

I do not know what "implicit grand client" means, please explain.

Comment 2

[Jared Kerim [:jkerim]]

Sorry, I wasn't clear enough, I mean that for initial launch the only FXA authentication flow will be triggered within the Android client.  There will be no way to sign in via FXA from the website.  However, down the line, that functionality is planned for future versions.

Comment 3

[Ryan Kelly [:rfkelly]]

:thumbsup: from me on generating these credentials.

>  for initial launch the only FXA authentication flow will be triggered within the Android client. 
> There will be no way to sign in via FXA from the website.  However, down the line, that
> functionality is planned for future versions.

OK, then just as an FYI, you'll need a second set of FxA credentials when you come to implement this functionality, please don't re-use the client_id from the android client code.

> The client-id needs to be marked as an "implicit grant client" in order to work correctly

This basically means that the client is allowed to directly prompt the user for their credentials and generate its own oauth tokens, rather than bouncing through our server via a redirect flow.  Since you don't want a redirect URL, this client will have to be marked as "canGrant: true".

I wouldn't mind taking a quick look over the client code for this, just to make sure I understand what will be happening.  Jared, can you please link me to the appropriate client-side code?

Comment 4

[Chris Kolosiwsky [:ckolos] (ckolos has left the building)]

:rfkelly - https://github.com/mozilla-services/location-leaderboard

Comment 5

[Ryan Kelly [:rfkelly]]

> this client will have to be marked as "canGrant: true".

Looks like I misunderstood the proposed flow here, the client should be "canGrant: false".

Comment 6

[Jared Kerim [:jkerim]]

The stumbler client and Leaderboard server will be using the FXA oauth redirect flow for sign in and will not be generating their own tokens or receiving FXA credentials directly from the user.

The client constructs a login URL using a similar method to this:

https://github.com/mozilla-services/location-leaderboard/blob/master/leaderboard/fxa/client.py#L10-L31

(Note: this is used for debug purposes and is not the actual code used to build the login url in the stumbler client)

The leaderboard server requests the following permissions

- 'profile'
- 'leaderboard'

See here:

https://github.com/mozilla-services/location-leaderboard/blob/master/leaderboard/settings.py#L141

We use the profile:uid to identify the user and profile:displayName to set their name which will publicly appear on the website.  We could potentially request these two individually rather than in aggregate as 'profile' if that will simplify and/or improve security.  

We also request the custom 'leaderboard' permission so that an access token granted for the leaderboard is not valid to request profile data from another application.  Originally, I was going to validate that an access token passed by the client is authorized against the set of scopes we've defined, however I can not find an API endpoint which, given an access token, returns the list of scopes for which it is authorized.  Perhaps I misunderstood the proposal of how to ensure that an access token is valid for my application.

Requesting the 'profile' and 'leaderboard' permissions together requires that the client id in use by a leaderboard deployment be flagged as a 'trusted client' in the FXA database.  If we do not want to flag the leaderboard as a 'trusted client' then we will need to change the set of scopes that are being requested.

The android client goes to the FXA login pages, logs in directly, authorizes, gets redirected back to the leaderboard server which validates and exchanges the code for access and refresh tokens and then passes them back to the client.  Only the client stores the access and refresh tokens.

The redirect handler is here:

https://github.com/mozilla-services/location-leaderboard/blob/master/leaderboard/fxa/views.py#L51-L95

We return the access token and the refresh token to the client.  The server stores neither, it only stores the FXA uid.  When the client makes an authenticated call to the server, it passes the access token in through an auth header, which the server unpacks and validates against FXA here:

https://github.com/mozilla-services/location-leaderboard/blob/master/leaderboard/fxa/authenticator.py#L28-L72

It takes the uid that was returned by the FXA profile call and looks that up in the local user table.  If the FXA call is unsuccessful, we fail to identify and authenticate the user and the call fails.  At the same time, we attempt to unpack the 'displayName' field from the profile call and store it against our local user object.

The client exchanges its refresh token for a new access token at client init time, and this is facilitated by the server through the refresh endpoint here:

https://github.com/mozilla-services/location-leaderboard/blob/master/leaderboard/fxa/views.py#L101-L114

I believe that covers the significant portion of the FXA integration for the geolocation leaderboard.

You can test a working version of it by going here and logging in:

http://leaderboard-dev.jaredkerim.com/api/v1/fxa/login/

Please advise as to whether we should use the set of scopes described here and have the leaderboard client id flagged as 'trusted client', or if we should restrict the set of scopes to something allowed by an untrusted client.

Comment 7

[Ryan Kelly [:rfkelly]]

> The client constructs a login URL using a similar method to this:

By the way, we now have an OpenID-Connect-compatible discovery endpoint that can tell you, among other things, the right URL at which to start the oauth dance:

  https://accounts.firefox.com/.well-known/openid-configuration

The idea being that the client only needs to know "accounts.firefox.com" and can look up all the other endpoints it needs, rather than having to hard-code lots of details about our URL structure.  You're not required to use it, just pointing it out as it's pretty new.

> I can not find an API endpoint which, given an access token,
> returns the list of scopes for which it is authorized. 

The `/v1/verify` endpoint returns the list of scopes associated with a token:

  https://github.com/mozilla/fxa-oauth-server/blob/master/docs/api.md#post-v1verify

I'm thinking about an addition to this API that lets you pass *in* the expected scopes, rather than having to go through the returned list of scopes and look for the ones you expect.

> We also request the custom 'leaderboard' permission so that an access token granted
> for the leaderboard is not valid to request profile data from another application.

OAuth scopes are additive, so IIUC this won't have the desired effect.  A token with scope "profile leaderboard" is valid to access both the profile data, and the leaderboard service.  So if some other application can e.g. steal the access token out of the client, then it could us it to read the user's FxA profile data.

It sounds like your ideal security situation would be for the client code to hold a token with only "leaderboard" scope..?

> If we do not want to flag the leaderboard as a 'trusted client' then we will
> need to change the set of scopes that are being requested.

All the above said, I'm happy to treat leaderboard as a trusted client since we control the code on both sides.

I suggest we spin off a separate bug for further discussion on the details of the flow, rather than forcing :ckolos to follow along in this ops bug.

Comment 8

[Ryan Kelly [:rfkelly]]

> I suggest we spin off a separate bug for further discussion on the details of the flow

Filed Bug 1243174