[michaelt]

It's kinda normal that you'd want to let a user log in and return them to the page they were at.

For example, if you're making a shopping website and a user asks to put something in their basket and you send them to log in, you'd want to return them to the item they were about to buy, not dump them back at the homepage.

What's the proper way of doing this, without "abusing state" ?

[madeofpalk]

At the least you're supposed to validate the at the returning "state" parameter is the same value as what you sent (using cookies or local storage).

Ideally you would 'consume' the token before redirecting, and not send it to the second redirecting url.

[pravus]

There's no reason to have a URL (or any data) encoded in the state parameter. The purpose of the parameter is to provide an opaque lookup key which you can utilize to provide correct, validated responses. This is usually done in some sort of database or Redis-like cache. My workflows have always used a random UUID for the state key and I just encode the necessary (validated) data items needed for the next step as a JSON blob. It's essentially a very short-lived web session.

If for some reason you really do need to transmit this data in-band (ultra rare use case) you should at least be using something like HMAC to verify that all carriers have transported the data unmodified. It is your responsibility to ensure the integrity of the data end-to-end.

[johncolanduoni]

Don't attach the sensitive URL parameters to the second redirect. The first redirect logs you in via cookie, and then if the second redirect is on the right origin it will have access to your cart.

[Operyl]

Store the basket in a temporary cookie, not the oauth state parameter.

[lstamour]

Also only allow redirects to your domain or website, not literally anywhere on the internet. And the token should stay in your website’s cookies - it’s unclear why the second redirect would ever need to pass a token if it can read it from site cookies in the first place.