Noticed this while testing a different bug. If you start a social authentication flow with a particular (non-default) auth tree but then change you mind and return to AM to login via a different tree (e.g. with the default username and password flow) then AM immediately starts the social login flow again and redirects you back to the social provider.
- Start a login with `&service=Google-AnonymousUser` (one of the example trees)
- Auth at Google will fail as an invalid client_id is configure
- Manually navigate back to AM without including a service parameter
Should be able to login to AM using the organisation default service. (In Firefox and Chrome, in Safari I do get the default login behaviour).
Immediately redirected back to Google.
I guess we are putting something into sessionState to preserve the current auth tree across the redirect. We should probably instead use the OAuth `state` parameter to encode any state we need to preserve, as that is what it is for.