Handle URN redirect_uris for Loop

[ckarlof]

To support this: https://bugzilla.mozilla.org/show_bug.cgi?id=1041814

[seanmonstar]

Absolutely, as soon as I get name and redirectUri. Don't need dangling useless clients in the config.

[ckarlof]

/cc @tarekziade

[vladikoff]

@ckarlof we might need this for testing on latest, etc.

name : Hello,
redirectUri : {LOOP_SERVER}/fxa-oauth/redirect

where {LOOP_SERVER} is the loop api server, not the standalone client for now?
?

[ckarlof]

For our dev servers, you can just make a PR: https://github.com/dannycoates/fxa-dev/blob/master/roles/oauth/templates/config.json.j2#L23

[ckarlof]

My understanding is that the product name is "Firefox Hello", but let @rfeeley and @johngruen confirm. I don't know if the name should be "Firefox Hello" or just "Hello".

As far as a redirect_uri, Hello doesn't have a "Web flow" that supports FxA. FxA integration is entirely in the browser at the moment. Perhaps we should have it be fxa://oauth/?

The situation we don't want to show the link back to the relier is after the user clicks on her verification email after creating her account:

[ckarlof]

New idea, for Loop we'll make the redirect_uri:

urn:ietf:wg:oauth:2.0:fx:webchannel

From what I can tell, this convention was first used by Google and others to signal the application uses application-specific "out of band" ways to get the code to the relier (with urn:ietf:wg:oauth:2.0:oob). We know how we'll deliver it to the relier, so let's make it explicit.

mozilla/fxa-content-server#1585 (comment)

[seanmonstar]

Since Loop has credentials, but oauth-server goofs on URNs, i've commandeered this issue to fix URNs.