Add "resume" to email verification and password reset links

[ckarlof]

This would be to enable clients to resume oauth flows. We're currently funneling the redirect URI and service (for client_id), but not the state.

[ckarlof]

This would also require adding state as an optional param in the account creation and password reset and verification email sending API endpoints.

[ckarlof]

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.

[ckarlof]

@dannycoates, I'd like to get this out in the next train (train-21).

[dannycoates]

The ambiguity of the term "state" is confusing me here. Is this just a "pass-thru" value like the redirectTo or are we storing state in the database? Maybe a more specific name would make it more clear.

[dannycoates]

I'm calling the parameter resume that the caller can set to a tag, 16 char alphanum for now, like service. If we need this to allow more data we can relax the validation.

Does the name and type make sense?

[ckarlof]

Unfortunately, I'm asking for state because that's what it is called in the OAuth RFC, and it's what we use in the rest of the system. I don't think the RFC specifies any length limits for state. It's totally up to the relier what to put in there, but it should of course be properly URL encoded. In terms of a length limit, I think we should have one, but it needs to be (much) larger than 16. It's entirely possible a client will want to put in an encoded JWT.

The more name translations we need to do in the client, the more confusing it gets. oauthState is a reasonable alternative, but IMO resume will be a confusing renaming to the client side devs.

[dannycoates]

@ckarlof thanks for the context. I think I'm gonna hurl.

[ckarlof]

No, you're right. Let's go with resume.

After we needed the third param to this, I should have re-evaluated it all. We need service for the server metrics, but if we add resume with a large limit, then the client side can just stick an encoded JWT in there with whatever OAuth params it wants, we won't need to bother you again. ;) Thanks!

[shane-tomlinson]

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]

@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!