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

Thomas Broyer t.broyer at gmail.com
Tue Feb 17 09:51:00 UTC 2015


One issue with this scheme is that this is typically implemented as web
page with <img> elements and a <meta refresh> to redirect to some other
place after all images have loaded, but empty/blank in all other aspects.
That means that an misbehaving RP could impair the UX of the whole
"platform" (and more specifically the OP) if it doesn't respond in a timely
manner. Because there's no way to indicate timeouts in HTML, the only way
to workaround this is to add JavaScript (setTimer in DOMContentLoaded, to
trigger redirection before onload if that ones takes too much time,
possibly cancelled in onunload if onload comes fast enough –shouldn't
technically be needed, but not all browsers behave the same IIRC); and/or
to add a message with a link to be clicked "if logging out takes too much
time".

Otherwise OK with the proposal overall. My notes below:

I don't quite understand why it talks about the end_session_endpoint and
post_logout_redirect_uris; it should just defer to RP-Initiated Logout,
saying it extends it (so it must indeed be supported by the OP).

In “OP Logout Functionality”, “register this related metadata value” should
probably be “advertize this related metadata value”.

What claims should be included in the id_token? What does the "exp" claim
would stand for? IIUC, the "exp" claim for the ID Token initially returned
during authentication represents the authentication expiration [1], but the
logout_uri is called after the authentication has been revoked or has
expired here, so the "exp" claim cannot have that meaning in this specific
case. Should the id_token here be generated specifically for this call,
with a very short expiration? or should/could it be the same as the one
last sent to the RP during authentication? How should the RP validate it?
(because it's not “received via direct communication between the Client and
the Token Endpoint”, I suppose the RP MUST validate the signature?)

[1] This, to begin with, is really not clear at all; it's only said once
“in passing” in <
https://openid.net/specs/openid-connect-core-1_0.html#Authentication>
without even mentioning the "exp" claim explicitly (“The Authentication
result is returned in an ID Token, as defined in Section 2. It has Claims
expressing such information as the Issuer, the Subject Identifier, when the
authentication expires, etc.”; and note that this section, and thus this
sentence, is absent from openid-connect-basic-1_0 for instance.) The "exp"
claim is always defined as the “expiration time on or after which the ID
Token MUST NOT be accepted for processing”, which is reflected in the “ID
Token Validation” section <
https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation>,
but that one only applies to validating the id_token received during
authentication, not how the OP should validate id_token_hint at the
authorization endpoint or end_session_endpoint, or the id_token at the
logout_uri here. FWIW, I had originally understood that as that the ID
Token could have a validity timeframe of a few minutes only, and that's how
I implemented it! And the examples using an ID Token with a validity
timeframe of 1000 seconds (approx. 15 minutes) don't help in the
understanding. It's never said either how an RP should behave should the ID
Token expire: should it re-authenticate (possibly using prompt=none and
id_token_hint –note that the ID Token could have expired here, so having a
definition of how the OP should validate it would be great) to check the
user is still authenticated at the OP and possibly get a new ID Token?

On Tue Feb 17 2015 at 03:45:31 Mike Jones <Michael.Jones at microsoft.com>
wrote:

>  An updated version is attached.  Changes were:
>
> 16-Feb-15            Added an optional id_token parameter to the
> logout_uri to authenticate requests and differentiate between sessions,
> plus related metadata values.  Added that non-200 HTTP status codes can be
> used when the logout fails.  Clarified when post-logout redirection to an
> RP occurs.
>
>
>
> I believe that this addresses the comments received to date.
>
>
>
>                                                                 -- Mike
>
>
>
>
>
> -----Original Message-----
> From: Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net]
> On Behalf Of Mike Jones
> Sent: Sunday, February 15, 2015 11:03 PM
> To: John Bradley; Torsten Lodderstedt
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] OpenID Connect Logout using HTTP GET
>
>
>
> I'm increasingly thinking that we should allow the OP to include the ID
> Token for the RP as a query parameter in the logout request.  I'm thinking
> this for two reasons:
>
> 1.  It would validate to the RP that the logout request is legitimate.
>
> 2.  It would tell the RP which session to log out, should multiple users
> be logged in at the RP from the OP.
>
>
>
> I don't think we should make including the ID Token required, since
> deployment circumstances will differ.  In some cases, the extra validation
> is important.  In others, it isn't.
>
>
>
> If we do this, in the Discovery and Recovery metadata, we should have the
> RP and the OP say whether the require and provide the ID Token value as
> part of the logout message to the RP.
>
>
>
>                                                                 -- Mike
>
>
>
> -----Original Message-----
>
> From: John Bradley [mailto:ve7jtb at ve7jtb.com <ve7jtb at ve7jtb.com>]
>
> Sent: Sunday, February 15, 2015 11:34 AM
>
> To: Torsten Lodderstedt
>
> Cc: Thomas Broyer; Mike Jones; openid-specs-ab at lists.openid.net
>
> Subject: Re: [Openid-specs-ab] OpenID Connect Logout using HTTP GET
>
>
>
> Both
>
>
>
>
>
> forcing a user to logout of a RP might also be used as part of a larger
> phishing attack, especially if the IdP returns the user to the bad guys
> landing page by redirecting to the post_logout_redirect_uri.
>
> That redirect URI needs to be registered but without authenticating the RP
> via having a id_token for the user Bad RP A could log the user out of all
> sessions and redirect the user to itself, without the user currently being
> logged in.
>
>
>
> Without the id_token all the IdP can do is log the user out of all
> sessions.
>
>
>
> Though when we start talking about IdP session management things get a bit
> fuzzy,  Many IdP will automatically log the user back in to a RP if they
> are still logged in to the IdP, the IdP may not have any real notion of
> state per RP connection.
>
>
>
> John B.
>
> On Feb 15, 2015, at 1:29 PM, Torsten Lodderstedt <torsten at lodderstedt.net>
> wrote:
>
> >
>
> >
>
> > against the RP or the user?
>
> >
>
> > Am 15.02.2015 um 17:22 schrieb John Bradley:
>
> >> It might be used as a denial of service via xsrf.
>
> >
>
>
>
> _______________________________________________
>
> Openid-specs-ab mailing list
>
> Openid-specs-ab at lists.openid.net
>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>  _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150217/c2c307c6/attachment.html>


More information about the Openid-specs-ab mailing list