feat(config): Add a /.well-known/fxa-client-configuration endpoint

[rfk]

The new /.well-known/openid-configuration has proven a big hit with client implements [1] but it doesn't include all the endpoints necessary for a Firefox device to bootstrap itself into talking to our servers. Rather than add additional fxa-specific keys in an otherwise spec-driven config document, what if we added a parallel config file that's specifically for rich clients that talk our various custom protocols?

It might look like this:

$ wget -q -O - https://accounts.firefox.com/.well-known/fxa-client-configuration
{
  "auth_server_endpoint": "https://api.accounts.firefox.com/v1",
  "oauth_server_endpoint": "https://oauth.accounts.firefox.com/v1",
  "profile_server_endpoint": "https://profile.accounts.firefox.com/v1"
}

Like the OIDC discovery document, it would allow you to specify a single base URL of "my FxA instance is at https://accounts.firefox.com" and discover all the other endpoints you need to know from there. Also like the OIDC discovery document, it doesn't contain any provisions for namespacing or versioning or discovery of other arbitrary services or any of the other rabbit-holes that have prevented us from shipping this sort of thing in the past. It's a simple JSON blob to make a small but real difference to easy of client implementations.

Unlike the OIDC discovery document, it hands out server root URLs and lets the client construct sub-paths that it needs, rather than including a separate key for each possible operation within the protocol. Our clients do this already, so it matches their behaviour, so meh.

It also doesn't specify the sync tokenserver URL or the location of any other identity-attached services. The fxa-content-server doesn't currently need to know these locations and I'd prefer it to stay that way, but might be talked out of it in the specific case of sync.

/cc @ncalexan; @shane-tomlinson r?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1237406

[shane-tomlinson]

auth_server_endpoint or just auth_server, or auth_server_root? To me endpoint implies a URL to a specific resource, whereas these are partial URLs. The OpenID Connect Discovery Spec use of _endpoint implies a full URL to a specific resource too. Examples from the OpenID Connect Discovery Spec:

"authorization_endpoint":
     "https://server.example.com/connect/authorize",
   "token_endpoint":
     "https://server.example.com/connect/token",
   "userinfo_endpoint":
     "https://server.example.com/connect/userinfo",
   "end_session_endpoint":
     "https://server.example.com/connect/end_session",
   "registration_endpoint":
     "https://server.example.com/connect/register",

[shane-tomlinson]

I like the concept, with some Q&Cs:

1. How come only servers are listed and not each endpoint the clients may need to talk to?
2. If only servers are specified, _endpoint implies a URL to a specific resource, perhaps _root is better.
3. You enable HTTP caching with a cache-control header. The response is pretty small, but the use of ETAGs might in theory speed things up if it reduces the number of TCP packets that need to be transferred when the resource cache expiry date has passed. (Could also be a total premature optimization)

[shane-tomlinson]

Oh, and add some tests please. :D

[rfk]

After a bit of travel and PTO, I'll be picking this up again this cycle.

To me endpoint implies a URL to a specific resource, whereas these are partial URLs

Fair point. I think s/endpoint/root/ makes sense.

How come only servers are listed and not each endpoint the clients may need to talk to?

Because it's most inline with what clients currently do, and our API has a lot of surface area. (e.g. would we have separate endpoints for signing up, signing in, cert signing, device registration, session invalidation, etc...?). There's scope to add those in the future though.

Oh, and add some tests please.

👍

[ckarlof]

Not to nitpick the milestone, but is this part of https://mozilla.aha.io/features/FXA-65?

[rfk]

Yes, yes it is; clearing milestone entirely while it's back in the backlog

[ckarlof]

https://bugzilla.mozilla.org/show_bug.cgi?id=1249520 is blocked on this. If there's movement on this, please update the Bugzilla bug.

[rfk]

We're trying not to keep backlogged PRs open; closing this out, we can always bring it back later when we get back around to finishing it up