[Openid-specs-ab] Expected Identity

Justin Richer jricher at mitre.org
Mon May 14 22:00:48 UTC 2012


Blaine, your timing is spot on -- I was actually just discussing this 
very use case here this afternoon in the context of one of our projects. 
I think there's a definite need for indicating what the starting 
identity was in the transaction, even if for sanity checking cases. But 
more to the point, you don't want to cause all RPs to force a prompt for 
all users just in case they might run into the problem below. 
Ultimately, I see it as another bit of information, a hint, that the RP 
can send to help the IdP do its job.

After thinking through it a bit, I think that the Request Object might 
be the best place to put something like that into. It makes it possible 
for RPs that care about it to do the legwork, but it doesn't further 
pollute the OAuth Auth Endpoint namespace for the simple cases that 
might not care.

Should we put this in as an issue?

  -- Justin

On 05/11/2012 09:23 PM, Blaine Cook wrote:
> Hi all,
>
> I'm trying to implement sign-in for a site using a combination of
> OpenID 2.0, OAuth (Facebook / Twitter), and ideally OpenID Connect
> once it's done.
>
> My user interface for sign-in starts with the asking the user for
> their email address, since I also allow password-based sign-in for
> users who don't have or don't want federated sign-in.
>
> The problem I'm facing is that there isn't a causal connection between
> the identity provided by the user and the identity that I get back
> after they complete their federated sign-in. For example, a user might
> try to sign in using a friend's computer. The best possible steps with
> OpenID 2.0 or OpenID Connect are as follows:
>
> 1. The user enters "bob.example at gmail.com" as their email address and
> is sent to Google to sign in.
> 2. Their friend, "alice.example at gmail.com" is already signed in at
> Google, and has already given my app permission to rely on Google as a
> single sign-on provider.
> 3. The user is transparently redirected back to my site.
> 4. The token I attempt to use is for "alice.example at gmail.com";
> clearly, though, this doesn't match Bob's expectation.
> 5. I refuse to sign in "alice.example at gmail.com", since the requested
> user was "bob.example at gmail.com"
> 6. I redirect to Google, this time insisting that Google ask the user
> to sign in.
> 7. The user clicks "Sign in as a different user"; at this point,
> Google needs to remember that we're still in the middle of a sign-in
> flow (Yahoo's OpenID system fails at this point)
> 8. The user signs in as "bob.example at gmail.com" and is redirected back
> to my site.
> 9. I sign-in "bob.example at gmail.com"
>
> For SPs that *do not* provide a mechanism to insist that the user
> signs in (i.e., the server doesn't implement prompt=login), this
> approach fails at step #5, at which point I need to display a
> confusing message indicating to the user that they should *first* sign
> out of Google, *then* return to my site in order to sign in. This
> option sucks, but is necessary for e.g., Yahoo.
>
> Sometimes, depending on how the SP implements prompt=login, the sign
> in may have the already signed-in user inaccessible in the sign in
> form (i.e., only the password field is available for entry),
> necessitating that the user explicitly sign out before signing in;
> this can be very annoying on shared computers (and unnecessary, since
> the login for "bob.example at gmail.com" need only persist for as long as
> is necessary to sign Bob in on my site). In this case, this process
> fails at #7.
>
> An alternative is possible:
>
> If OpenID Connect were to have (like the BrowserID 'requiredEmail'
> attribute[1]) a parameter (e.g., "requiredIdentity") that meant "only
> authenticate this user; do not allow any other users to authenticate,
> and present a successful sign-in if and only if this user has
> authenticated; otherwise, produce an error", then the following
> workflow would be possible:
>
> 1. The user enters "bob.example at gmail.com" as their email address and
> is sent to Google to sign in.
> Ignored: 2. Their friend, "alice.example at gmail.com" is already sign in
> at Google, and has already given my app permission to rely on Google
> as a single sign-on provider.
> 2. Bob authenticates at Google, proving that he is "bob.example at gmail.com"
> 3. Google redirects back to my site.
> 4. I sign-in "bob.example at gmail.com"
>
> There are never more complex flows, other than the normal "user can't
> successfully sign in" flow which is already required to handle a
> normal and necessary failure case.
>
> Please consider adding this parameter to OpenID Connect – as a website
> implementor, this feature is probably necessary for me to be able to
> confidently provide OpenID support to my users. The alternative is a
> sprawling and error-prone mass of code to deal with all of the
> potential scenarios that might arise, as only hinted at in the first
> user experience example.
>
> Best,
>
> b.
>
> 1. https://github.com/mozilla/browserid/blob/dev/example/rp/index.html#L186
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab



More information about the Openid-specs-ab mailing list