[OpenID] What about Logout?

Peter Watkins peterw at tux.org
Wed Apr 8 17:42:26 UTC 2009

If a user is authenticated to RP1 by virtue of an assertion issued by the
OP, then what's the value of "logging the user out" of RP1 if the user is
still logged in to the OP? All the user need do in many OpenID use cases is
click a few links to have the OP issue new assertions to log the user back in
to RP1 -- so being logged in to the OP is pretty darn close to being logged
in to every RP that accepts the OP's assertions. There might be some ancillary
benefit to the logout-of-RP-only model. For instance, if the RP site has
some webapp security flaws *and* the OP login assertion process has good
protection against attacks like CSRF, then logging out of the RP would help
protect RP assets against attacks on the flawed RP app. But it seems a
little screwy in a federated identity/authentication system to say the user
is logged out of the RP if the OP still recognizes the user as logged in there.

A good logout mechanism, and I think SAML had this but my memory is rusty,
would also have an RP-OP exchange mechanism for the RP to provide to the OP
some information (URL with a nonce) about how the OP can let the RP know that
the user has logged out of the OP. Users should have the option of logging
out of the OP and effectively terminating their sessions at RP1 and RP2 
without their user agent interacting with RP1 or RP2.

Giving the OP a mechanism to log a user out of all RPs would also introduce
the possibility of realtime OP assertion revocation. Suppose Google is your
OP, and through analysis of your traffic to Gmail or maybe the Urchin servers
Google ascertains that your system has been compromised with some malware.
If the Google OP could send messages to each RP that had relied on an assertion
about your identity, then Google could limit the malware's ability to damage
your reputation or assests that you control via webapps that use Google OP

Deron Meranda wrote:
>> I think it might be a reasonable extension for the OP to provide
>> a URL to the RP, which the RP can later redirect the user to when
>> the RP's session is terminated.  This OP-provided URL can
>> then do whatever the OP wants; such as offering to log the
>> user out of the OP, etc.  Of course there should be no automatic
>> action!

I think that's a good option to provide, too. Generally I think logout 
should happen at the OP, but certainly this suggestion is an improvement
over the idea of logging out of RP1 without any easy way to log out of
the OP. 


On Wed, Apr 08, 2009 at 08:08:31AM -0700, Peter Williams wrote:
> In our environment, a user typically has several SSO sessions open at several RPs, each operating in different (sub) domains. Some subset of them (called them RP1  and RP2) may be sharing session management with Facebook - the OP.
> We have been told numerous times by folks in control of their business rules that any decision to logout the user from one RP1 MUST not log the user out of RP2. Assuming RP1 and RP2 are both talking to Facebook OP, RP2 must be able to continue to use its association to the OP after a logout exchange between RP1/OP, without the user having to re-authenticate (create a new IDP session).

More information about the general mailing list