Interruptions in authentication process

Allen Tom atom at yahoo-inc.com
Wed Jan 13 17:51:05 UTC 2010


A potential issue is that supporting checkid_immediate makes it impossible
to support the switch users feature.

At Yahoo, we do not support having simultaneous authentication sessions for
different accounts on the same browser. It¹s theoretically possible to do
this, however, I think that many users might be confused by the behavior.

Allen


On 1/12/10 5:02 AM, "George Fletcher" <gffletch at aol.com> wrote:

> Regarding case B...
> 
> At AOL if the user is already authenticated but has not given consent to be
> "identified" to the RP we show a consent screen and allow the user to logout
> and login as a different user (a.k.a. "switch users"). Also on this consent
> screen we allow the user to permanently remember their consent decision. This
> effectively give the user seamless SSO the next time they log into that RP. Of
> course these consents can be revoked by the user.
> 
> One of the issues of "switch user" is that it terminates the previous web
> session. So if the user was reading mail for the first user, their mail
> session is logged out. It's possible to keep these authentications separate
> but in the end that seems more confusing for the user than helpful.
> 
> I'm curious as to others experience.
> 
> Thanks,
> George
> 
> On 1/11/10 7:54 PM, Allen Tom wrote:
>>  
>> Hi Alex -
>> 
>> I agree with Breno that cases A and C require the user to restart the
>> process from the beginning. Given that the user indicated that they wanted
>> to authenticate using an account at the OP, presumably the user chose an OP
>> for which they already have an account and remember the password, so
>> hopefully A and C are edge cases.
>> 
>> Our statistics indicate that the overwhelming majority of the time, the user
>> is already signed into Yahoo when the Yahoo OP receives an authentication
>> request. I believe that other OPs have also observed similar behavior.
>> 
>> B is definitely an interesting case, as people often have several accounts
>> and may want to "switch users" before signing into the RP. I think the best
>> UX would be for the OP's approval screen to indicate which account the user
>> is currently signed in with, and an option to sign in as a different user.
>> 
>> Allen
>> 
>> 
>> 
>> 
>> On 1/11/10 3:01 PM, "Breno de Medeiros" <breno at google.com>
>> <mailto:breno at google.com>  wrote:
>> 
>>   
>>  
>>>  
>>> For many RPs, if user starts processes A or C (with regards to their
>>> in-house login system), I assume it'd still be often the case where
>>> the user will have to re-start the process from the original context.
>>> 
>>> Case B is more interesting as it raises issues exclusive to use of a
>>> (open) federated login system.
>>> 
>>> On Mon, Jan 11, 2010 at 14:44, Alex Barth <alex at developmentseed.org>
>>> <mailto:alex at developmentseed.org>  wrote:
>>>     
>>>  
>>>>  
>>>> 
>>>> In the course of ironing out workflows between OpenID provder and OpenID
>>>> relying parties it I am facing usability problems that I'd like to submit
>>>> here to the attention of some more experienced OpenID developers than I am.
>>>> 
>>>> I am interested in any feedback, pointers to existing conversations,
>>>> sections in current and future specs that I may have overlooked etc.
>>>> 
>>>> Here is the problem: There are some actions that can occur during
>>>> authentication where a user can fall through the cracks:
>>>> 
>>>> A User is redirected with an authentication request from RP to OP, requests
>>>> a new password on OP, email client opens different browser for a one time
>>>> password reset link embedded in the email.
>>>> B User is redirected with authentication request from RP to OP, but would
>>>> like to log in with different user than the one currently authenticated on
>>>> OP, user is logged out and session is deleted.
>>>> C RP offers OP as identity provider, user selects OP, is redirected with
>>>> authentication request to OP. User does not have an account yet, creates
>>>> one, confirms email address, but again, email client opens different
>>>> browser
>>>> (similar to A).
>>>> 
>>>> In all of these scenarios the user's session and with it her authentication
>>>> request is lost - the authentication process is stuck in its tracks.
>>>> 
>>>> Is the assessment of the problem flawed? Is there a solution in the specs
>>>> that I am overlooking?
>>>> 
>>>> Thank you for your input.
>>>> 
>>>> Alex Barth
>>>> http://www.developmentseed.org/blog
>>>> tel (202) 250-3633
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> specs mailing list
>>>> specs at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>> 
>>>>       
>>>>  
>>>  
>>> 
>>> 
>>>     
>>>  
>>  
>> 
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>> 
>>   
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100113/269d79ea/attachment.htm>


More information about the specs mailing list