OpenID Connect – Logout/Session Mgmt (Part 2)
Session Topic: Open ID Connect: Session Management / Logout Discussion (Part 1 & Part 2)
Tuesday 4A & 5A
Convener: Mike Jones; John Bradley; Naveen Agarwal
Notes-taker(s): Mike Jones
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Participants also included:
Torsten Lodderstedt
Chuck Mortimore
Brian Campbell
Alan Karp
Breno de Medeiros
John Pinter
Bill Mills
Back channel logout
Multiple RP sessions might be logged in at once
OP doesn't have session identifiers
Torsten - back channel logout has been shown to cause problems
Chuck - the session-based SAML logout doesn't work well and isn't supported
Brian - requiring JavaScript on every page a non-starter in enterprise contexts
Alan Karp - Better UI could help users better understand what's actually going on
John - one requirement can be extending session lifetimes across sessions
Chuck - The only session state typically present is the session cookie
Brian - SAML has fragile redirect chain
- Another means is for the IdP to do a GET to each RP endpoint
- Ping is currently implementing something like that
Naveen - Unless the browser tab is active, the JavaScript logout doesn't work
Naveen - Yahoo had a variant where they stored state for all sessions in a single cookie
Brian - Doing GETs to single-pixel images, which trigger logouts
John - The RP could check the referer if it wants to secure the logout
- But in general, not protectable against XSRF
Chuck - Browsers are getting better about preventing cookie state manipulation in iframes
Torsten - Will check what DT is doing
John - ID Token "exp" claim doesn't trigger logout in practice
Naveen - We could just document both front channel mechanisms as optional
- Enterprises might choose one method, the Web might choose another
- We should document both as a next step
Mike - If we support multiple mechanisms, the RPs would get to decide
John - Back channel notification is yet a third mechanism
David Pinter - The front channel won't always be available
Bill Mills - Security policy may require ability to kill all sessions
John - A compromise back channel mechanism is notifying RPs on the back channel of a state change
Mechanisms:
- postMessage:
- Pro: RPs get notifications, minimal web traffic
- Con: Requires RP JavaScript
- Doesn't work when RP tab not active
- image/iframe GETs:
- Pro: Doesn't require JavaScript
- Still uses session cookies
- Con: IdP needs to track active RP sessions
- Ugly logout page
- All RPs might not be notified before the browser is closed
- Pro: Doesn't require JavaScript
- backchannel notifications:
- Pro: Works even when RP tab not active
- Con: Requires RP logic to identify and communicate with session to logout
- IdP scaling issues
Chuck - Current spec doesn't work for enterprise use cases because of JavaScript requirement
- and because the RP must be active for the logout to work
Chuck - We didn't put "jti" in the ID Token - we could for enabling logout
- That would enable correlating back channel notifications received to active sessions
- Open questions about whether to use the same ID in multiple responses to same RP
- Probably use a separate session identifier that is not "jti"
Dale - Back channel notification is effectively ID Token revocation
Chuck - The OP wants to be authoritative for the session ID
Chuck - Revoking a session could be done like an OAuth revocation
- OAuth revocation supports CORS and JSONP
Actions:
- Add image/iframe description to Session Management
- Also describe back channel mechanism
- Then we decide what to do after that
Naveen, Breno - Google is planning to build a token caching layer
- It would get tokens at login time and clear them at logout
- It would send notifications when things change
- It would communicate internally with postMessage
- postMessage requires a security layer
George - How is this like the Trusted Agent in the Native Applications work?
Naveen - It's a lot like that