Add support for "access_type" oauth parameter, for requesting refresh tokens

[rfk]

In mozilla/fxa-oauth-server#260 we're moving towards a "refresh token" model for oauth tokens. In this new world, access tokens will expire after some short timeframe. For reliers that require ongoing access to profile information, they can request a special "refresh token" that will allow them to mint new access tokens at will.

For context, the overall flow is quite similr to the way that Google does it [1] and goes like this:

• The relier requests GET /authorization?client_id=blahblah&access_type=offline to indicate they want a refresh token.
• The oauth-server redirects to the content server to begin the oauth dance.
• The content-server processes the authorization and does POST /authorization { assertion: blahblah, access_type: "offline" } to complete the dance, then redirects back to the relier.
• The relier takes the code from the redirect, posts it to the oauth-server like POST /token { code: "XYZ" } and gets back a refresh_token along with the usual access_token: { access_token: "ABCDEF", refresh_token: "UVWXYZ" }.
• The access_token can be used straight away to access oauth-protected resources, just like it can now. But it will expire after a short while (currently on the order of weeks, but we may shrink that).
• When the access_token expires, the relier can use the refresh_token to request a fresh access_token by doing POST /token { refresh_token: "UVWXYZ" }, without involving the user again.

The content-server's responsibilities in this dance will be:

• Accept access_type=[online|offline] when beginning the oauth dance, and remember that state.
• Somehow indicate to the user that they're giving the relier ongoing access to their data.
• Echo back the access_type parameter when creating the oauth code at the end of the dance.

/cc @seanmonstar

[1] https://developers.google.com/identity/protocols/OAuth2WebServer#offline

[rfk]

FWIW, this is the UI that Goog throws up when requesting offline access:

(I've already granted pocket permission to read my profile data, so the offline-access thing is the only query in the prompt).

We should consider doing something simlar eventually, but initially I think it would be OK not to add any additional UI around this. After all, it's currently the default behaviour.

[vladikoff]

from meeting:
should be landed with refresh tokens
one train after the work week

[shane-tomlinson]

@rfk - what is the timeline for this? @zaach thinks train-41

[rfk]

How feasible would it be to get just these two components into train-40?

• Accept access_type=[online|offline] when beginning the oauth dance, and remember that state.
• Echo back the access_type parameter when creating the oauth code at the end of the dance.

And iterate on any changes to the UI from there? IIUC that change can safely go live on the same train as the oauth-server backend changes, since it doesn't change how any existing APIs will be called.

[shane-tomlinson]

How feasible would it be to get just these two components into train-40?

This will likely cause other items to get bumped. A full cycle, starting with train-41, is more comfortable.

[rfk]

nod, especially coming into whistler

[rfk]

@zaach sorry, pinching this issue for @seanmonstar who expressed interest in having a go at it this week :-)

[rfk]

This was fixed by #2615