[Openid-specs-ab] About ID Tokens being access tokens

Tue Aug 30 15:21:02 UTC 2011

P.S. Having summed up the history -- I am actually OK with using
access token to obtain id_token if the first access token is suitably
constrained in such a way that it can only be used against the
userinfo endpoint. This is equivalent in constraining the 'scope' such
that it MUST NOT include anything but the Connect scopes. Returning
id_token together with access_token then is just an optional
optimization for the latency. I think this approach is cleaner.
Downside is obvious: more optional portion means more interoperability
issues though.

2011/8/31 Nat Sakimura <sakimura at gmail.com>:
> 2011/8/30 Andreas Åkre Solberg <andreas.solberg at uninett.no>:
>>
>> On 30. aug. 2011, at 11:54, Nat Sakimura wrote:
>>
>>> 2011/8/30 Andreas Åkre Solberg <andreas.solberg at uninett.no>:
>>>> However, and as Nov commented, I did a mistake by including the scope
>>>
>>> I guess it was Nat's comment :-)
>>
>> You're right, sorry :) Hope to meeet you once, so that I can associate a face with the nov, nat, john, mike  and ...
>>
>
> You can see me here http://wp.tv/mc701107 :-)
>
> I intend to ustream the coming OpenID Summit in Mountain View, so you
> probably will be able to see Mike and John in action as well.
>
>>> The point Google was making is that "login" and "profile data
>>> processing" have different latency tolerance. Typically, "login" is
>>> much shorter so that the relying party can start serving the customer
>>> immediately while profile data can be fetched background. So, the user
>>> info endpoint latency is a lesser issue than id_token.
>>
>> I see that, it makes sense.
>>
>>>> considered also pushing the user data JWT in the response to the code?
>>>
>>> Yes. This is exactly what we did in the first draft (a.k.a. Artifact Binding).
>>> However, as you point out below, it moves further away from OAuth proper.
>>> (It can be an extension, and thus not so much different than id_token,
>>> but we decided that it should be just a regular OAuth resource, thus
>>> UserInfo Endpoint.)
>>
>> OK. Good to know.
>>
>>> The security characteristics is that the token endpoint MUST NOT
>>> return id_token more than once,
>>
>> I understand that returning an id_token in return to a 'code' should be done only once. Mostly because the code is sent front-channel, cached in the user agent history, and the server logs.
>>
>>> and MUST NOT return id_token unless it
>>> is in the user in-presence (browser) session. Otherwise, the user may
>>> be being impersonated by the application.
>>
>> I'm not really sure if I get this. Except if you refer to a use case where an ID Token is issued with delegated access to access other resources; in example by using a 'shared aud(ience)'. I assume you are referring to the RP as the application, and not the user agent.
>
> Yes. OAuth Client, to be precise.
>
> Important distinction between Access Token and ID Token are as follows:
>
> 1) Access Token cannot expand the scope while ID Token may potentially
> have the power to do so.
> 2) Access Token can be long lived, but ID Token is valid only within
> the session.
> 3) Access Token can be presented to a third party OAuth resource while
> ID Token is not.
> 4) In the code flow, access_token is not exposed to the browser, while
> ID Token potentially is.
>
> Therefore, in general, you cannot issue an access token to a scope
> 'id_token'. If you do, the OAuth resource that the access token was
> used against may be able to obtain 'id_token' to create the session
> and impersonate the user at the Client.
>
> Check session endpoint interprets ID Token and returns the content of
> it if valid. It does not exchange Access Token to ID Token.
>
>>
>>> Thus, it can be returned in
>>> exchange to a 'code' or initial authorization request, but not against
>>> access_token nor refresh_token unless they are bound to a user
>>> in-presence (browser) session.
>>
>> I do not see how that is a show-stopper. If the Id_token JWT can only be issued when the user is present; then the token can be issued and cached at the server during authentication/authroization. And then the 'openid-session' access token will give you access to read the already cached id_token. Doing subsequent request to the check session endpoint will not issue a new id_token, but instead return a copy of the one issued when the user was present. This means that in the subsequent calls, the OP will only return something that the RP already has, and hence I do not see it as a security issue.
>>
>
> Not necessarily. As described above, a (third party) OAuth resource
> may also present the access token. Note that client credential is not
> presented at this time in OAuth so the authorization server has no way
> of distinguishing the intended Client and the impersonator.
>
> Also, even if it did the Client authentication, it does not mean that
> user is present. So, it is changing the semantics of ID Token. The
> Client impersonating the user at the Client does not make too much
> sense as an attack, but leaving that potential may lead to a bigger
> hole.
>
>
>
>>> Apparently, scope alone does not work.
>>
>> I'm not yet convinced, but I now know a lot more about the history, which is useful.
>>
>> Until now, the only real argument against this approach, that I have understood, is the added latency on getting session data. And this latency is a single additional back-channel call to the oauth protected check session endpoint. This call includes very little data, but will most likely include establishing a new tcp + ssl + https connection. Implementing optimalizations like a worker process with an open ssl + http 1.1 connecting, and requesting id_tokens over http pipelining may be a hassle to implement.
>>
>> I would be happy to accept that this single argument is important enough to ditch the proposal. But these use-cases are new to me. I've been involved in several SAML POST versus Artifact binding discussions, and latency have never been such an important factor.
>>
>> Andreas
>>
>>
>>
>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en