<html><head/><body><html><head></head><body>Hi Justin, <br>
<br>
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.<br>
<br>
regards,<br>
Torsten.<br><br><div class="gmail_quote"><br>
<br>
Justin Richer <jricher@mitre.org> schrieb:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif; margin-top: 0px">Issues #787 was recently filed, asking to open up the restrictions <br />around when to return id tokens from the token endpoint. Currently, this <br />is restricted to the authorization_code grant type and no others, but it <br />has been proposed that this is too restrictive and that there are use <br />cases to allow returning of id tokens from assertions and refresh tokens.<br /><br />However, Brian and I both think that the return from a refresh token is <br />a potentially dangerous break from previous notions of what the id token <br />represents. To me at least, the id token always represented a handle on <br />the user's session that contained a directly accessible pack of <br />information about the current user. The refresh token, on the other <br />hand, is a long-term delegation that in many cases never expires. I <br />could therefore get a "fresh" id token from a
grant
that happened months <br />ago, and that doesn't seem right to me. It could be very dangerous for <br />an app to pretend that a user is still logged in and authorized by their <br />IdP by perpetually refreshing the id token in the back channel like <br />this. Yes, an app can already do this by setting some kind of local <br />cookie that never expires or any number of other things, but is this a <br />pattern we want to tacitly encourage? I would argue that if you can <br />refresh an id token like this, it becomes even less distinct from the <br />existing access token.<br /><br />As such, I believe that if you want to extend the session, you should do <br />so in a way that directly uses the existing session key. What I proposed <br />a few months ago, and what we've implemented here, is a method that uses <br />the ID token itself as an JWT Bearer Assertion in a call to the token <br />endpoint. The AS can then make the decision if the id token is being <br />presented
in a
context that it makes sense to extend. And in this case, <br />you're trading one ID token for another, and not getting a *new* one <br />through the back channel.<br /><br />It was suggested on the call this morning that we relax the language in <br />the spec to say that an ID token MAY come back from any grant, but that <br />we have something in the security considerations dictating the possible <br />pitfalls. So it's those pitfalls that I'd like to discuss here -- are <br />there horrible things that could really happen here, or am I simply <br />jumping at shadows?<br /><br />-- Justin<br /><hr /><br />Openid-specs-ab mailing list<br />Openid-specs-ab@lists.openid.net<br /><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br /></pre></blockquote></div></body></html></body></html>