2066516 - Support authentication in a "sync decoupled" state

Status: ASSIGNED

(Firefox for Android :: Accounts and Sync, task)

Description

[Segun Famisa [:segun]]

After bug 2064408, the next step in actually decoupling is telling Firefox Accounts (FxA) that an authentication is happening in "decoupled" mode.

There are a couple of concerns and proposals for the way to do that. One way is ensuring that we are not passing sync scope, and there are other combinations of possibilities being discussed, so the details for this unfortunately, are not yet defined.

What is guaranteed, is that we definitely need keys_optional (bug 2064408), but what it means to send a "decoupled authentication request" is still being ironed out.

I'll update this bug with details when we have them. (Applying a 13 point for now, since it's an unknown)

Comment 1

[Segun Famisa [:segun]]

It seems that this work will now depend on fxa_client persisting and keeping track of the granted sync scopes. The details of the work is TBD.

Comment 2

[Segun Famisa [:segun]]

We discussed moving this to milestone 3.

Comment 3

[Mark Hammond [:markh] [:mhammond]]

what it means to send a "decoupled authentication request" is still being ironed out.

FWIW, all auth requests will be "coupled" to something - just not necessarily sync. There will be no concept of "sign in, but don't enable any services" - all signins will be a path to something specific being enabled.

(re-auth is subtly different though as described in bug 2065982)

Comment 4

[Lauren Zugai]

It's possible this is better as a separate ticket as I see mention of fxa_client above, but dropping this comment as a continuation of where this piece first came up in this Android spike doc/thread.

Per option 3 in ADR 0049 and reaffirmed in later discussions, you can drop the scope parameter here in favor of just sending us service. FxA will determine whether or not Sync will be granted as well (always send us keys_jwk as a query param so we can grab the sync key if the user enters a password), and we will send you back what scopes were granted in the fxa_oauth_login web channel message.

In the discussions that happened later (WIP ADR 0052), Dan, Mark, and I are aligned that we'd like "scope mapping" sent to FxA over the fxa_status web channel message, under capabilities. Send us what the browser supports (Desktop will be sending us a 'smartwindow' service):

...
keys_optional: true,
services: {
  sync:  { scope: ['https://identity.mozilla.com/apps/oldsync', 'profile'] },
  relay: { scope: ['https://identity.mozilla.com/apps/relay', 'profile'] },
  vpn:   { scope: ['https://identity.mozilla.com/apps/vpn', 'profile'] }
}

For the re-auth piece mentioned by Mark above, you can send the scopes you determine the user should have without service, and we will grant those.

Timing: we'd like this in place before Android sync decoupling reaches production so we can delete our own mapping rather than maintaining it for one or two Firefox versions. We have the FxA piece to remove our mapping and read from the web channel message tracked in https://mozilla-hub.atlassian.net/browse/FXA-14509.

Comment 5

[Segun Famisa [:segun]]

accidental comment

Comment 6

[Segun Famisa [:segun]]

The completion of this work is blocked by bug 2074136

We need fxa-client to drop the scopes url param when we are authenticating in a decoupled state.

We will still work on the android-side logic of adding the services in the web channel message (bug 2074157), but the eventual completion of "supporting authentication" in a decoupled state is blocked on that part.

Comment 7

[Segun Famisa [:segun]]

unassigning, so it does not seem like this is being worked on, while I am working on the child - bug 2074157