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

Thomas Broyer t.broyer at gmail.com
Thu Feb 26 09:35:05 UTC 2015


On Wed Feb 25 2015 at 18:39:52 Brian Campbell <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 redirects to youtube.com, which serves an empty
image" (or yahoo.com redirects to flickr.com, or microsoft.com redirects to
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/63e86b9e/attachment.html>


More information about the Openid-specs-ab mailing list