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

Vladimir Dzhuvinov / NimbusDS vladimir at nimbusds.com
Mon Mar 4 13:35:36 UTC 2013


I would second that the id_token should not be confused with and
overloaded with the semantics of a session token.

Vladimir

--
Vladimir Dzhuvinov : www.NimbusDS.com : vladimir at nimbusds.com




-------- Original Message --------
Subject: Re: [Openid-specs-ab] Returning ID Tokens from Refresh Tokens
From: John Bradley <ve7jtb at ve7jtb.com>
Date: Fri, March 01, 2013 2:32 pm
To: Mike Jones <Michael.Jones at microsoft.com>
Cc: "openid-specs-ab at lists.openid.net"
<openid-specs-ab at lists.openid.net>

One thing we need to be clear on with tokens issued from the token
endpoint no matter the grant type is that they represent the
authentication event used to get the token (refresh/assertion/id_token)
that is being used to request the id_token.

This is NOT a back channel way to see if a user is still logged in.


The main reason someone would do this based on a refresh token is to get
a id_token with a different audience or perhaps different claims (I
think Google refers to this as side scoping if I recall correctly).


I understand that some people think doing this as part of refresh adds
to possible confusion by the client.  Remember that it is the client
that is requesting this in the first place and if it dosen't understand
the semantics of a id_token based on a refresh grant type it will just
ignore the extra parameter in the response.


The other approach where we create a new grant_type that takes a
id_token, perhaps refresh token and maybe a request_object is a larger
undertaking.  It was pam that pointed out if you go down that road there
will be lots of people trying to pile on features.   This should be a
separate extension if people want it.


For the refresh grant type allowing the AS to cache the info about the
id_token that was originally issued with that refresh token and return
it again when the refresh token is used should not be precluded.
I do agree that we do probably need some rules around the question of
"iat" , "exp" , "azp" , "acr" and "aud" changing if that is allowed. 
There is a question if this is part of the messages or core spec or a
separate profile of the refresh grant.


John B.
On 2013-03-01, at 12:53 AM, Mike Jones <Michael.Jones at microsoft.com>
wrote:

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 OfTorsten
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> 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  grantthat 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 acontext 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
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



_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab


More information about the Openid-specs-ab mailing list