Provide a way for reliers to confirm a user's login state without re-entering password

[rfk]

This is a followup to mozilla/fxa-content-server#6658 and in service of mozilla/addons#732.

To support enforcing 2FA on developer accounts in AMO, they'd like to do a flow like the following:

1. Have the user do an initial FxA OAuth flow without requiring 2FA.
2. Lookup the resulting userid in the AMO database to see if they're a developer.
3. If so, check whether they used 2FA during the login at (1).
4. If not, have the user do another FxA OAuth flow, this time passing query parameters to insist that they use 2FA

Such a flow is possible as of train-124, thanks to #6545 which added support for the acr_values query parameter. However, due to various rough edges in our session handling (#5916), the user will be forced to enter their password twice - once for the OAuth flow at (1) and again for the OAuth flow at (4).

Can we provide a way for the relier to avoid a second password prompt at (4), that doesn't allow them to skip the initial authorization step at (1)?

┆Issue is synchronized with this Jira Task
┆Issue Number: FXA-736

[rfk]

One option would be to use the id_token_hint parameter from OIDC, which provides a way for the relier to explicitly pick up from a previous authentication flow:

https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest

Essentially:

• During the initial login, request the openid scope in order to obtain an id_token representing the user's login attempt. (Reliers should be encouraged to do this anyway).
• When re-authenticating an existing login, include the id_token in the OAuth request as ?id_token_hint=<token>.
• We can verify the provided id_token and, if valid and relatively recent, can opt not to show the password prompt to the user.

Requiring an id_token prevents unauthorized reliers from bypassing the password prompt, and it means that authorized reliers can have control over whether or not they want to use this flow. If the user signs out of AMO, then it would discard the id_token, and so the user would have to re-enter their password the next time they try to sign-in to AMO.

[rfk]

(This would essentially implement a small part of the OIDC prompt=none flow, which we've had other requests for in the past).

[philbooth]

@rfk can you triage out of backlog if that's the wrong place for this?

[shane-tomlinson]

ref mozilla/fxa-auth-server#2708

[shane-tomlinson]

ref #640

[rfk]

In a bit more detail, here's what would be required for id_token_hint approach described above:

• Add id_token_hint as a parameter on the OAuth relier model.
• During setup of the model, validate that id_token_hint contains a valid id_token
  • We could post it to a server-side verifier, or check the JWT signature in web content
  • If the given id_token is invalid, or its audience doesn't match the requesting client, error out.
• During signin, if a valid id_token_hint is present:
  • treat the signin as a force_auth flow for the user identified in said token.
  • if we have an existing sessionToken for that user, use it without any further prompting (don't prompt for their password, don't show the "continue to X" button, nothing)

I think this would give us all the desired properties, and interact nicely with #589 to allow AMO to guide developers into setting up 2FA on their account.

[shane-tomlinson]

Ref #1979 to support RP initiated logout.

[jaredhirsch]

I'm not sure if there's engineering work here beyond what's captured in #2132. Leaving unestimated.

[data-sync-user]

➤ Jared Hirsch commented:

I think we're safe to dupe this to https://jira.mozilla.com/browse/FXA-261.

[data-sync-user]

➤ Jared Hirsch commented:

Closing as a dupe of 261.