OpenID Connect – Logout/Session Mgmt (Part 1)

From IIW

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
  • 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

Retrieved from "https://iiw.idcommons.net/index.php?title=OpenID_Connect_–_Logout/Session_Mgmt_(Part_1)&oldid=19677"