Send "resume" parameter to supported auth server calls

[ckarlof]

Context: mozilla/fxa-auth-server#762

With resume we'll be able to send whatever encoded OAuth context we want. I propose putting the client_id, state, and redirect_uri in an encoded JWT and putting it in resume wherever we're setting service. We still need to set service because it's used for server side metrics, but we can stop setting redirectURL.

This should clean things up a bit.

Items remaining:

• - Update the fxa-js-client - in progress - see feat(client): Pass along the resume parameter to the auth-server fxa-js-client#132
• - Update the email templates - see mozilla/fxa-auth-mailer@0b98847
• - Pass in a Relier and FxaClient to each View and remove any singletons. - See refactor(client): Create one FxaClient and one Relier in app start. #1645
• - Add resume to the Relier model on the client. - See feat(client): Forward the resume token to the auth server #1646
• - Update client side tests.
• - Roll a new fxa-js-client with feat(client): Pass along the resume parameter to the auth-server fxa-js-client#132 - - 0.1.25 created.
• - Create resume from URL search parameters and send to fxa-js-client
• - If user verifies in a second client, ask them for their password and sign them in so they have a sessionToken to fetch a code. See Send "resume" parameter to supported auth server calls #1623 (comment) for more context.

[ckarlof]

Landed in auth server in train-21: mozilla/fxa-auth-server@36f9e28

[ckarlof]

This is a *** feature in train-22.

If the user creates an account, opens her verification link in a different browser, and then continues in that browser to the relier, our return request will lack the state originally given to us by the relier. In fact, we return some "different browser" error instead.

IMO, it's our responsibility to pass the state back regardless, and the relier's responsibility to respond to the different browser case. Also, the relier might be using the state for other reasons, and it's a flaw that we're not giving it back to them in this case.

The auth server has added a resume parameter for us to use here. Since we might shove other crap in there later as well, I propose we put the state in there as an encoded JWT with one property: state. Other suggestions?

FWIW, the reason this is important is to help make Marketplace's migration work when the user chooses to use a different email address for her FxA and then verifies and continues in a second browser. Corner case for sure, but as @ryanfeeley says, we need to make the Web less excruciatingly painful.

[pdehaan]

we need to make the Web less excruciatingly painful.

That @ryanfeeley guy should work in marketing. Or at least get that printed on his business cards.

[ckarlof]

I made it my Twitter tag line.

[shane-tomlinson]

@ckarlof - once the verification email is opened and the user is back at the content server, what responsibilities does the content server have? Does it need to decode the resume JWT, pull out the encoded fields, and redirect?

A question that should precede the following - how is the resume field generated? Does the RP take care of that, our client library, or do we do it in the Relier?

[ckarlof]

A question that should precede the following - how is the resume field generated? Does the RP take care of that, our client library, or do we do it in the Relier?

We discussed in the standup, but resume will be created and managed by the content server code.

[shane-tomlinson]

@ckarlof - I'm going to need a bit of hand holding and wanna get some clarity before you head out on vacation.

If the user creates an account, opens her verification link in a different browser, and then continues in that browser to the relier, our return request will lack the state originally given to us by the relier. In fact, we return some "different browser" error instead.

IMO, it's our responsibility to pass the state back regardless, and the relier's responsibility to respond to the different browser case. Also, the relier might be using the state for other reasons, and it's a flaw that we're not giving it back to them in this case.

The auth server has added a resume parameter for us to use here. Since we might shove other crap in there later as well, I propose we put the state in there as an encoded JWT with one property: state. Other suggestions?

I am looking at how to create a JWT over on the jwcrypto docs.

I can create a JWS as in the example:

jwcrypto.sign(payload, keypair.secretKey, function(err, jws) {
       // error in err?

       // serialize it
       console.log(jws.toString());
    });

I can pass that jws to the auth server as the resume parameter.

In the verification code, I can decode that jws using verify:

   // verify it
    jwcrypto.verify(signedObject, publicKey, function(err, payload) {
      // if verification fails, then err tells you why
      // if verification succeeds, err is null, and payload is
      // the signed JS object.
    });

To do that, I need the public key from the original keypair.

If I create a key pair for the signing, I can store those in localStorage, and decode the jws - in the same browser. This doesn't really help the case where the user verifies in a second browser, unless the client can fetch the public key for the user from the server?

On a second browser, I could manually decode the jws and not verify, but that doesn't seem like the right thing to do.

[ckarlof]

Crap @shane-tomlinson, I'm dumb. I didn't mean JWT. I meant "web safe Base64 encoded JSON", e.g.,

resume=WebSafeBase64Encode('{"state":"123"}')

It doesn't need to be signed. I'm sorry about the confusion.

[shane-tomlinson]

Copying over this comment from mozilla/fxa-auth-server#762 (comment).

---

Related to the work we're doing in #784 for Marketplace migrating their existing accounts. If the legacy (migrating) user verifies her email on a second device and continues there, it will be useful to be able to pass the state to Marketplace to allow the user to continue the migration.

@dannycoates, @ckarlof - To resume on a second device, we need to be able to generate an assertion. Generating an assertion requires a signed certificate, which requires a sessionToken. Neither /recovery_email/verify_code nor /password/forgot/verify_code return a sessionToken. We can get around this by forcing the user to enter their password in the second browser, or we could have those two API calls return a sessionToken. I propose we return a sessionToken.

[shane-tomlinson]

@ckarlof and @dannycoates - @johngruen and @ryanfeeley say that it's OK to ask the user for their password in the second client, no new auth-server support needed. Thanks!

[ckarlof]

I didn't think this through enough. The state is also intended to be used as an anti-forgery token. When verifying on a second browser, even if the user enters her password, then anti-forgery check isn't going to pass on the relier, which is going to be a problem.

If we have mozilla/fxa-auth-server#763 (have email verification call return a sessionToken), then we could do something like:

• user clicks verification link
• we finish oauth flow and send back state
• relier detects that state doesn't match its current session
• relier regenerates state for client session and re-requests auth for email address
• some magic happens where we don't show any UI and just re-auth the user

the last step would probably be some rule like, if

• the email parameter exists
• we have an active session for that email
• the relier is whitelisted

then we just auto-finish the OAuth login for that account without showing any UI.