Open ID Connect Logout Mechanisms Progress + Status
Open ID Logout
Tuesday 2A
Convener: Mike Jones
Notes-taker(s): Mike Schwartz
Tags for the session - technology discussed/ideas considered:
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Unlike the other parts of the OpenID Connect specification, logout is still
in flux. There are three different approaches: session management,
front channel (passing logout via browswer), and back channel (passing
directly to RP).
The mechanims we are discussing are for the OpenID Connect provider to communicate to the RP's that a logout event happened--i.e. Single Logout (SLO).
Front Channel is easy to implement, via POST or an iFrame HTTP method, and perform logout in browser. Problem is that its not a reliable communication channel--what if the logout never actually occurred. Closing the browser used to do the job, but now that doesn't work in many cases.
Back Channel can be more reliable, but its much harder to implement. For example, at EIC a financial trading firm mentioned a use case where an iFrame is used to provide a single experience for a future trading site. This user needs to make sure you are logged out of both the trading firm, and the backend future trading site.
Session Management using an OP iFrame inside every RP website, and counts on the fact that the OP knows when the session script changed. Other javascript asks the OP iFrame if the user logs out. Its ok to poll frequently, because its just a inter-browser communication. There was resistence to adding Javascript to each page.
Also, there was problems with the RP not getting the javascript running if the tab was closed, although you would be logged out properly if you were to return to the site.
Back Channel Logout Discussion
Logout token is similar to an id_token, but has extra claims: jti, logout_only, and sid (session id). Also its prohibited to put a nonce in a logout token. The idea is that you should never be able to confuse an id_token with a logout_token. SID is used to refine the scope of the logout to one session.
Back channel works for native apps. IDP may want to put a cookie to register the device on first use.
Tokens are supposed to be one-time use. You post it...
- Discovery Values:
Can OP support it Optional feature: backend_logout_session_required Identifier from the OP for the RP to use for that session.
Front Channel Logout Discussion
You have a URI that the RP registers at registration time--this is the location of the iFrame that if rendered, will log me out. Clear cookies, and change html5 local state. The reason why its an iFrame (v. img tag), is that in an iFrame you can invoke futher down logouts.
You may have a logout button at your RP or at your OP. The identity provider could provide a special button to enable the RP to signal a global logout. Its up to the IDP to decide what kind of UI the IDP wants to provide.
This approach was used not too successfully with SAML, but its the best compromise.
Is session identifier required?
In some cases, you may want an opaque identifier, by putting a session identifier in the id_token, and to pass that session identifier as a param on the logout URI. IDP may not act on the logout unless the session id matches.
This session identifier may have different characteristics than previously specified. In this case, its not signed, its a bearer secret.
RP initiated Logout message has a state value which can be sent by the RP in the host_logout_redirect_uri as a param. The OP should pass this back to the RP.
There is a misalignment between the enterprise and consumer markets. In the consumer world, the goal is to obfuscate your identity from the RP. In the enterprise world, there are security compliance issues. Also in the consumer space, families using shared devices may need to switch identities.
There is an open issue in the OpenID Working Group to Create a document describing the "single logout" semantics, and use cases.
