Logout specs are inconsistent in defining a session
Issue #1024
resolved
the front channel logout spec defines: Session Continuous period of time during which an End-User accesses a Relying Party relying on the Authentication of the End-User performed by the OpenID Provider. But the spec also says: [The sid's] contents are opaque to the RP. And this value seems to bear no clear relationship to what the user agent and the RP decide the session should be. The sid is just a value (claim) from the OP that it regurgitates when it sends a logout.
Comments (5)
-
reporter
-
The session being referenced is the RP's session for the user at the OP. Yes, the RP has its own implementation-specific session state, which may be cookies, HTML5 local storage, database entries, etc. which it will clean up upon logout, but what that is is outside the scope of the OpenID Connect logout specs.
I will look at possible clarifications to that effect.
-
- changed milestone to Errata
-
-
assigned issue to
Michael Jones
-
assigned issue to
-
- changed status to resolved
The logout specs are now clearer about the responsibilities of the RP and OP in maintaining and responding to changes in session state. Especially see the new text in RP-Initiated Logout in commit https://bitbucket.org/openid/connect/commits/847be44033ed41e8080b760f3c3a0302318d248f .
- Log in to comment
After a conversation with a member of this wg, it appears that the working assumption for the 2 logout specs is that the user sessions with the OP and RP are fully synchronized. If that is so these specs should bluntly assert that they are not to be used if synchronization is not maintained. Here is my response on the other thread.
Sure, with oidc the sessions can (& imho should) be created asynchronously. So given the requirements of GDPR the initial session between the user and the RP should have the minimum claims known to be required. If at a later time the user decides to release additional claims to the RP from the same or a different OP, the original OP claims are retained and new ones added. Per security requirements (eg owasp) a new session with the RP must be established, which doesn't necessarily require a new one with the original OP.