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

[Torsten Lodderstedt]

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 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
>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/8d794923/attachment.html>