[Openid-specs-ab] OpenID Connect Logout using HTTP GET

Mike Jones Michael.Jones at microsoft.com
Thu Feb 26 16:36:48 UTC 2015

I’ll plan to remove “STS” from the next version.

From: Brian Campbell [mailto:bcampbell at pingidentity.com]
Sent: Thursday, February 26, 2015 6:51 AM
To: Thomas Broyer
Cc: Mike Jones; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] OpenID Connect Logout using HTTP GET

Yeah, I suppose a single logout_uri could do its own redirects to cope with different domains. And has some flexibly in how it does that via the logout_use_iframe registration concept. Our approach was img/get only and we were trying to avoid assuming or demanding that an RP/client be able to do the redirects like that and also trying to avoid doing a chain of redirects under one image get. But for this spec, a logout_uri might well be sufficient.
STS is typically short hand for "Security Token Service." I find that many people think of an STS as something that does token exchange with 'active' clients using something like WS-Trust. While Microsoft tends to use the term more broadly to also include things that do web SSO like SAML, WS-Federation and OpenID Connect. I'm not suggesting either is right or wrong - just that there does seem to be different connotations and so it'd be good to expand on the meaning in this context.

On Thu, Feb 26, 2015 at 2:35 AM, Thomas Broyer <t.broyer at gmail.com<mailto:t.broyer at gmail.com>> wrote:

On Wed Feb 25 2015 at 18:39:52 Brian Campbell <bcampbell at pingidentity.com<mailto:bcampbell at pingidentity.com>> wrote:
Sorry, took me a while to get to looking at this (even at 2 pages).
In general this looks pretty good and isn't too far off from the implementation we did. Ours is img/get based and has no sid or equivalent. But it's pretty close otherwise.  A few comments and questions follow...

"Several OpenID Connect implementers have requested a front channel logout mechanism that doesn’t use JavaScript. " -> it's not the use of JavaScript, per se, but rather the nature of how JavaScript is used. The session management spec pretty much requires that an RP have Connect aware JavaScript on every page, which is a non-starter for many scenarios that involve low-touch or no-touch integration with existing applications.
RPs/Clients can have multiple redirect_uris and, if they have different domains, it can be problematic for a front-channel logout mechanism that's relying on cookies when only one logout_uri is allowed. We allowed for multiple logout uris in our implementation to account for this. I can't remember if we just hit them all or try and chose from among them based on the redirect_uris used in the corresponding SSOs. I think the former. I don't know if that's something that a logout spec should account for but it's a sitation that can fall out of multiple redirect_uris.

Couldn't the logout_uri do redirects to cope for that situation?
Something like "google.com<http://google.com> redirects to youtube.com<http://youtube.com>, which serves an empty image" (or yahoo.com<http://yahoo.com> redirects to flickr.com<http://flickr.com>, or microsoft.com<http://microsoft.com> redirects to live.com<http://live.com> if you prefer ;-) ).

If no "post_logout_redirect_uri" is provided to the "end_session_endpoint", is it expected that the OP keeps the user post logout (rather than sending them back to the RP)?  I kind of assume so but it's not practically clear (to me anyway) in this doc or in Session Management. FWIW, the implementation we did always keeps the user at the OP after logout.

FWIW, I assumed the same (we do redirect to the post_logout_redirect_uri though after logout)

"STS" is a bit of an overloaded term that means different things to different people/groups/companies. In a real spec its should be defined clearly or avoided.

I, for one, have no idea what STS means.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150226/d23c09ff/attachment.html>

More information about the Openid-specs-ab mailing list