Closed rfk closed 5 years ago
An alternative would be to do something similar to Google, and use a special "urn:ietf:wg:oauth:2.0:oob"
URI for this purpose, internally mapping it to our green-tick success page.
@rfk backlog or next?
Going to backlog for now but put this in my list to chat with @shane-tomlinson about when he returns.
An alternative would be to do something similar to Google, and use a special "urn:ietf:wg:oauth:2.0:oob" URI for this purpose, internally mapping it to our green-tick success page.
There's a whole IETF spec for native apps that includes a section on custom redirect_uri schemes which specify domains in reverse order. For example:
com.firefox.accounts:/oauth/success/3c49430b43dfba77
Per the spec an app would normally register a URL handler for the reverse URL. Upon successful authentication, the IdP redirects to special redirect_uri, the OS opens the app w/ the associated URL handler, and everyone is happy. We could simplify things slightly and instead of redirecting to the URL, consider it an internal URL and redirect to ourselves.
we put 127.0.0.1:3030 in dev config, and have this under control for now!
I just realized that in https://github.com/mozilla/fxa-auth-server/pull/2706, we added the reference-browser client_id to the dev config with a redirectUri of
"https://accounts.firefox.com/oauth/success/3c49430b43dfba77"
. It really should be referring to the hostname of whatever dev instance is running, not the production server!I'm not sure what the best way is to represent that in config. We could use just
"/oauth/success/3c49430b43dfba77"
but trying to do clever URL joinery on the redirectUri feels like it could end badly...