The FxA team recently included a well-known configuration file. It doesn't list everything, but it's better than hand configuring the myriad service endpoints in play. You can see the live version at https://accounts.firefox.com/.well-known/openid-configuration This ticket tracks querying that JSON blob at account creation time, extracting the service endpoints that we recognize, and configuring the Android Account with those endpoints. This is similar in spirit to Bug 1182263 (which stalled for complexity reasons) and Bug 1231549 (which needs to happen independent of this ticket).

rfkelly: I observe that the openid-configuration doesn't include the api-* endpoint. Is there a reason? If not, can you file and cross-link to include it?

(In reply to Nick Alexander :nalexander [Vacation PTO from Dec 23--Jan 4] from comment #1) > rfkelly: I observe that the openid-configuration doesn't include the api-* > endpoint. Is there a reason? If not, can you file and cross-link to > include it? Sorry, forgot the NI.

markh: Desktop should do something like this as well, and we should standardize on the pref name that we want to use for the endpoint to query (or re-use the fxa-content-server pref). Can you file the Desktop tickets?

> I observe that the openid-configuration doesn't include the api-* endpoint It's not needed as part of the OIDC flow; we should definitely expose it, leaving ni? for myself to file the bugs on our side

Also, in case it's not obvious, the existing contents of that document are derived from an OIDC spec: http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata If we add additional keys, we'll have to prefix them like e.g. "fxa_auth_endpoint" to avoid future collisions with updates to that spec. (Or use a whole different document like "/.well-known/fxa-configuration", but that discussion has always turned into a rabbit-hole). Nick, are the OAuth and Profile-related endpoints listed in that document suitable for your purposes, or would you need to do URL construction based on them? If the latter, let's just expose the raw endpoints for all the servers as keys you can use directly, and keep the OIDC ones for OIDC.

(In reply to Ryan Kelly [:rfkelly] from comment #5) > Also, in case it's not obvious, the existing contents of that document are > derived from an OIDC spec: > http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata > > If we add additional keys, we'll have to prefix them like e.g. > "fxa_auth_endpoint" to avoid future collisions with updates to that spec. > (Or use a whole different document like "/.well-known/fxa-configuration", > but that discussion has always turned into a rabbit-hole). > > Nick, are the OAuth and Profile-related endpoints listed in that document > suitable for your purposes, or would you need to do URL construction based > on them? If the latter, let's just expose the raw endpoints for all the > servers as keys you can use directly, and keep the OIDC ones for OIDC. No, we'd need to do some small parsing, so extracting the keys elsewhere sounds like a good idea. You can see the current endpoints used at https://dxr.mozilla.org/mozilla-central/source/mobile/android/app/mobile.js#951 and https://dxr.mozilla.org/mozilla-central/source/mobile/android/services/src/main/java/org/mozilla/gecko/fxa/FxAccountConstants.java#16

(In reply to Nick Alexander :nalexander from comment #3) > markh: Desktop should do something like this as well, and we should > standardize on the pref name that we want to use for the endpoint to query > (or re-use the fxa-content-server pref). Can you file the Desktop tickets? Because desktop already stores these endpoints in preferences, and (I assume) we don't want to assume self-hosters have this configuration endpoint, I guess we will need a sane way to spell the concept of "never query - these are the values we should use" vs "we should query, and these are the values we obtained when we did". I think it probably makes sense for desktop to hold off a little, see what Android ends up with, and then see how desktop can do (roughly) the same thing. I'll leave ni? on me for that.

(In reply to Mark Hammond [:markh] from comment #7) > (In reply to Nick Alexander :nalexander from comment #3) > > markh: Desktop should do something like this as well, and we should > > standardize on the pref name that we want to use for the endpoint to query > > (or re-use the fxa-content-server pref). Can you file the Desktop tickets? > > Because desktop already stores these endpoints in preferences, and (I > assume) we don't want to assume self-hosters have this configuration > endpoint, I guess we will need a sane way to spell the concept of "never > query - these are the values we should use" vs "we should query, and these > are the values we obtained when we did". I think we should assume that the service provides this configuration for every client sign in. Self hosters must always maintain their cluster to whatever Mozilla deems necessary; here's that rubber hitting the road. I see no value in accommodating self hosters who want to run an outdated fxa-content-server or fxa-auth-server.

(In reply to Nick Alexander :nalexander from comment #8) > I think we should assume that the service provides this configuration for > every client sign in. Self hosters must always maintain their cluster to > whatever Mozilla deems necessary; here's that rubber hitting the road. I > see no value in accommodating self hosters who want to run an outdated > fxa-content-server or fxa-auth-server. I think that's reasonable longer term, but I was just concerned about people who upgrade Firefox, realize their own server is a little behind, then end up needing to upgrade their server before Sync continues. If we don't care about that, I agree we can do whatever we want :)

(In reply to Mark Hammond [:markh] from comment #9) > (In reply to Nick Alexander :nalexander from comment #8) > > I think we should assume that the service provides this configuration for > > every client sign in. Self hosters must always maintain their cluster to > > whatever Mozilla deems necessary; here's that rubber hitting the road. I > > see no value in accommodating self hosters who want to run an outdated > > fxa-content-server or fxa-auth-server. > > I think that's reasonable longer term, but I was just concerned about people > who upgrade Firefox, realize their own server is a little behind, then end > up needing to upgrade their server before Sync continues. If we don't care > about that, I agree we can do whatever we want :) Ah, I see -- my PUT is that such configuration is one-time, at client sign in. Desktop allows folks to monkey with the prefs, but I think that's at best benign and at worst a footgun. Android doesn't allow it -- if you want to change, delete the Android Account and sign in again. I think it's reasonable for clients to balk at signing in to servers that don't support a feature.

A proposal for directly exposing the values you need in a similar, but separate document to the OIDC-specific one: https://github.com/mozilla/fxa-content-server/pull/3364

Sorry for the delay, but I opened bug 1249520 to track the desktop side of this.

I opened a new bug for this after discussion at the all-hands today, based on how it's implemented on desktop: Bug 1377012