[Openid-specs-ab] Returning ID Tokens from Refresh Tokens

[Mike Jones]

Responding to Justin, I don’t see the ability to return an ID Token from the Token Endpoint for grant types other than just “authorization_code” as being a break from what an ID Token standard for at all – let alone it being dangerous.  Here’s why…

An ID Token is a “Token that contains Claims about the authentication event”.  That would remain true.

On the call, I think someone was saying something like “but the ID Token would then not necessarily represent a logged-in user session”.  It never did.  It represents that the user had logged in.  If you want to know whether the user is still logged in, make a “prompt”:”none” request using the ID Token as the “id_token_hint” parameter value, and find out.  Or use Session Management, which will result in you knowing that the interactive user session was terminated within a small delta of time after it happened.  None of that changes.

What does change is that it’s no longer prohibited to return an ID Token from the Token Endpoint for grant_types other than “authorization_code”.  For instance, that might let some deployers use the “client_credentials” grant_type, which was previously prohibited.

I don’t see any practical downside to this change, whereas I do see upsides in the additional flexibility that it gives us.

                                                            -- Mike

P.S.  Pam used to have reservations about this change, but once she realized this afternoon that an ID Token never did represent a logged-in user session, she dropped her reservations.  I hope that you and Brian will do likewise, having thought about it some more, Justin.

From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Torsten Lodderstedt
Sent: Thursday, February 28, 2013 11:01 PM
To: Justin Richer; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Returning ID Tokens from Refresh Tokens

Hi Justin,

I don't see the difference between both approaches. The AS should be able to link the refresh token to authentication instant and session as well. So before issuing another id token it can perfom some checks. Moreover, the new id token should contain the original authentication instant and method. Thus a client may decide whether a fresh authentication is required.

regards,
Torsten.


Justin Richer <jricher at mitre.org<mailto:jricher at mitre.org>> schrieb:

Issues #787 was recently filed, asking to open up the restrictions
around when to return id tokens from the token endpoint. Currently, this
is restricted to the authorization_code grant type and no others, but it
has been proposed that this is too restrictive and that there are use
cases to allow returning of id tokens from assertions and refresh tokens.

However, Brian and I both think that the return from a refresh token is
a potentially dangerous break from previous notions of what the id token
represents. To me at least, the id token always represented a handle on
the user's session that contained a directly accessible pack of
information about the current user. The refresh token, on the other
hand, is a long-term delegation that in many cases never expires. I
could therefore get a "fresh" id token from a

 grant

that happened months
ago, and that doesn't seem right to me. It could be very dangerous for
an app to pretend that a user is still logged in and authorized by their
IdP by perpetually refreshing the id token in the back channel like
this. Yes, an app can already do this by setting some kind of local
cookie that never expires or any number of other things, but is this a
pattern we want to tacitly encourage? I would argue that if you can
refresh an id token like this, it becomes even less distinct from the
existing access token.

As such, I believe that if you want to extend the session, you should do
so in a way that directly uses the existing session key. What I proposed
a few months ago, and what we've implemented here, is a method that uses
the ID token itself as an JWT Bearer Assertion in a call to the token
endpoint. The AS can then make the decision if the id token is being
presented

 in a

context that it makes sense to extend. And in this case,
you're trading one ID token for another, and not getting a *new* one
through the back channel.

It was suggested on the call this morning that we relax the language in
the spec to say that an ID token MAY come back from any grant, but that
we have something in the security considerations dictating the possible
pitfalls. So it's those pitfalls that I'd like to discuss here -- are
there horrible things that could really happen here, or am I simply
jumping at shadows?

-- Justin

________________________________

Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto: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/20130301/c28a8185/attachment.html>