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

[Justin Richer]

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