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

[Andreas Åkre Solberg]

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 ...

> 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.

> 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.

> 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 know, 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4448 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110830/4211ca13/attachment.p7s>