gistfile1.txt

The Problem with Delegated Sign-in

Scenario:

The owner of tastybeer.com wants to use delegated sign-in, and not store users' passwords. They've seen the light and don't want a NASCAR array of sign-in buttons, and require the users' email addresses, so the sign-in form is simply:

[ fill in email ] [[ Sign In ]]

When a user, say [email protected], arrives at tastybeer.com, he enters his email address and begins to sign in:

[ [email protected] ] [[ Sign In ]]

tastybeer.com inspects Bob's address, and sees that gmail.com is an OpenID provider, so forwards our example user to Google's OpenID sign in page, using the discovered identifier: https://www.google.com/accounts/o8/id

Our example user is directed to Google, but is signed in with his work account, [email protected]. He completes the OpenID flow, and is directed back to tastybeer.com.

Tastybeer has two options: use the original address, but mark it as unverified (since the OpenID attribute exchange address doesn't match) or use the new address. The problem with the latter solution is that this conflicts with the user's expectation of how accounts and sign-in work.

The solution is (as AOL's OpenID provider does) to specify which user is expected to sign in.

This could work with OAuth "Connect"-like sign-ins as well. For example, Twitter's authentication URL could be:

https://api.twitter.com/oauth/authenticate?oauth_token=Z6eEdO8MOmk394WozF5oKyuAv855l4Mlqo7hhlSLik&[email protected]

and Facebook's could be:

https://www.facebook.com/dialog/oauth?client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&[email protected]

If the Identity Provider is unable to authenticate the specified user, then a failure message is produced. It's not necessary to log out any other user(s) already logged in, since the only real function of the OAuth authorisation endpoint in this case is to verify that a given user is able to authenticate (or not).