Having dealt with similar problems on the implementation side it's incredible how in this day and age it's still so difficult to pass state through sign-in or sign-up.
Half of the reason appears to be how the Oauth 2.0 standard is written - it purposefully forbids browser-specific items like the hash fragment in the URL. For passing state you have the "state" field but, despite the name, its original purpose was to prevent XSRF attacks, not store data.
Vendor libraries don't go to huge lengths to help here, as they settle on complying with the standard.
What if you're redirected to a different origin? Not a common use case, but it does occur when you e.g. have several services and select where to go in the sign-in form.
Ideally one should be able to pass structured state throughout, but all we have is `state` really.
True, but it's extremely effective at getting registrations, almost to the point that you're dooming yourself without it. Anyone and everyone uses it, big and small. Google can afford any random user to run a few queries before dangling the hook, but it's all the same.
Half of the reason appears to be how the Oauth 2.0 standard is written - it purposefully forbids browser-specific items like the hash fragment in the URL. For passing state you have the "state" field but, despite the name, its original purpose was to prevent XSRF attacks, not store data.
Vendor libraries don't go to huge lengths to help here, as they settle on complying with the standard.