[OpenID] Persistent logins

Max Metral max at artsalliancelabs.com
Tue Mar 13 17:20:18 UTC 2007


I was afraid this might be the case.  It's a pretty big hole I would
submit, because sites aren't going to make their members suffer by
having to login repeatedly (if they don't want to), but members
shouldn't have to answer that question many times, and I shouldn't have
to sacrifice the ability to undo a previous decision (on a different
machine).  So either the IDPs have to start implementing custom tools,
or the protocol needs an extension. (or I'm missing something)

In my past life I built Microsoft Passport, and I remember confronting
these same problems.  I won't bore (or somehow compromise) the list by
describing the solution, but suffice to say it was "unpleasant" but
worked.  In the end, if check_auth isn't server-to-server only, it would
seem we'd need that mechanism.  And it would be even better if the
consumer got to specify it's desire for that kind of assertion up front.

--Max

-----Original Message-----
From: Calvin Cheng [mailto:cxcheng at mac.com] 
Sent: Tuesday, March 13, 2007 1:15 PM
To: Nic James Ferrier
Cc: Max Metral; general at openid.net
Subject: Re: [OpenID] Persistent logins

Pardon me, I'm fairly new to the OpenID scene and here's my first post
to the list :)

As far as I can tell from the OpenID specs, there's no "single sign
off".
OpenID is not a distributed session management system.

In that sense, as started by Nic, the responsibility as entirely on the
application. Your custom app should need to check with the IDP that the
identity is still valid at regular intervals (every 10 minutes for
example, but perhaps not each time the session cookie is refreshed
depending on security requirements) that you determine. The end user
would need to inform the IDP to allow the RP to have access forever, or
be confronted with frequent authentication requests.

Do we have the recommended best practices for dealing with session
management?
 
On Tuesday, March 13, 2007, at 04:29AM, "Nic James Ferrier"
<nferrier at tapsellferrier.co.uk> wrote:
>"Max Metral" <max at artsalliancelabs.com> writes:
>
>> Our custom authentication system has a "remote logoff" capability.
>> Basically, if you ask it to "remember login" it writes a persistent
>> cookie that will "auto refresh" every 10 minutes or so (configurable
>> time).  This means that when you come to the site after that time has
>> passed, we verify a hash inside the encrypted cookie still matches
your
>> password.  So if you forget to logout, or your machine is
compromised,
>> you can change your password and those persistent cookies will become
>> invalid.
>>
>>  
>>
>> Now, we've added OpenID support to the system.  We still want to
allow
>> persistent logon.  If someone selects this option, how could I
possibly
>> provide the same "kill switch"?
>
>You still issue a session cookie right?
>
>The "logoff" is just invalidating the session cookie.
>
>
>This is something I've been thinking about a lot over the last 2 days
>tho... I think the "session" is just a marker for the authentication,
>a bit like authentication is sometimes used for a session (ie: with
>http auth).
>
>But if the user has "logged out" of the IDP then a session cookie will
>continue to work.
>
>I think issued session cookies should quite often check with the IDP
>to ensure that the user is still authenticated.
>
>
>-- 
>Nic Ferrier
>----------------------------------------------------------
>Need a linux/java/python/web hacker?  I'm in need of work!
>----------------------------------------------------------
>http://www.tapsellferrier.co.uk   
>_______________________________________________
>general mailing list
>general at openid.net
>http://openid.net/mailman/listinfo/general
>
>



More information about the general mailing list