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

Brian Campbell bcampbell at pingidentity.com
Thu Feb 26 14:51:25 UTC 2015

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> wrote:

> 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/3a96d76c/attachment.html>

More information about the Openid-specs-ab mailing list