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

[Nat Sakimura]

Semantically, ID Token is dubbing several roles:

1. the assertion that asserting the past front channel authentication event;
2. the detached signature for opaque tokens (access token and refresh
token);

>From the point of view of 2., there may be some value for it to be returned
in exchange to refresh token, but since it is all over the protected
channel, the benefit is marginal.

>From the point of view of 1., though it is bound when it was returned from
the authorization endpoint, I am not so sure whether it is bound to the
front channel session when it is returned from the token endpoint. The user
may have closed his browser before the code was exchanged to ID Token. So,
it may be legitimate to return ID Token in exchange of refresh token.

However, we probably need to define bunch of things for it to happen. For
example, the 'auth_time' MUST NOT be updated. 'exp' and 'iss' probably need
to be updated, etc.
Also, it is probably better to clearly mark that it was not issued in
response to 'code'.


2013/2/28 Justin Richer <jricher at mitre.org>

> 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 <Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/**mailman/listinfo/openid-specs-**ab<http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130228/2cf4d30a/attachment.html>