[OpenID] OpenID RP: Storing persistent identifier cookie rather than authentication ticket cookie

[George Fletcher]

I'm not sure I understand how this relates to storing/not-storing an 
"authentication token" as in most cases the "authentication token" has 
it's own expiry time and the best practice says...
> If they come back after their login has been expired, use an immediate 
> request to authenticate them.
The way I read this is that the RP stores the OpenID in a persistent 
cookie in-addition-to the any auth session cookies the RP may want to 
store. This way the user can be auto-logged-in "the next day" when their 
previous session has expired. I would equate this to the "Keep me signed 
in" or "Remember me" feature on many sites. I would continue to use this 
metaphor from a UI perspective as this is what users understand.

So 2 recommendations from my perspective...
1. Encrypted the OpenID in the stored cookie to protect from "cookie 
thieves"
2. Only store the cookie if the user selects the "Keep me signed in" option

My 2 cents:)

Thanks,
George


Andrew Arnott wrote:
> I was reading the RP best practices on the OpenID wiki and was 
> particularly interested its suggestion to use persistent cookies for 
> the identifier 
> <http://wiki.openid.net/Relying-Party-Best-Practices#StoreprimaryOpenIDinacookieandcheckimmediateatnextsession> 
> rather than the actual user authentication ticket. The idea being that 
> each user visit to the site invokes a checkid_immediate message to the 
> OP to see if the user is still logged into the OP, and if so, the RP 
> "resumes" the user's login session, otherwise the user must log in 
> again.  The persistent cookie stores the identifier that is used to 
> send the checkid_immediate message.
>
> I've heard some reactions by users who were new to OpenID that were 
> surprised that logging out of the OP didn't automatically log them out 
> of the RPs.  I know we've had several "single-sign-out" threads on 
> this list, and this seems like it would solve it with no change to the 
> OpenID spec. 
>
> I've never seen an OpenID RP actually behave this way, however.  It 
> does seem to introduce some new problems.  For example, if the RP 
> sends the user on a checkid_immediate redirect as soon as the user 
> returns to the RP and the OP happens to be down, the user is 
> effectively locked out of the RP because the OP won't return the user 
> to the RP.  To use a hidden iframe at the RP to attempt the 
> checkid_immediate could result in something like the Facebook 
> auto-login experience where the user sees the Facebook login page for 
> a few seconds and then is automatically dragged into his account, 
> which met with some "what the heck just happened?" questions from users.
>
> I'm building a feature into DotNetOpenAuth that will help RPs to use 
> this behavior, but I'm just wondering if anyone else has scouted out 
> this territory and have any suggestions.  I think the approach I'm 
> going to start with is the full-window redirect using 
> checkid_immediate, but I'll only try it at the user's /first/ request 
> for a session, so that if the OP doesn't return the user and the user 
> tries visiting the RP again, the second attempt will succeed and the 
> user will just have to log in explicitly (presumably using another OP).
>
> What do you all think?
>
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the 
> death your right to say it." - S. G. Tallentyre
> ------------------------------------------------------------------------
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>