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

[Nat Sakimura]

2011/8/30 Andreas Åkre Solberg <andreas.solberg at uninett.no>:
> On 29. aug. 2011, at 23:38, John Bradley wrote:
>
> As far as I know the token endpoint trades code for a access and refresh
> token,  or a refresh token for an access token.
>
> Yes.
>
> There is no scope parameter for the token endpoint only the authorization
> one.
>
> There is. See OAuth section 6.
>
> However, and as Nov commented, I did a mistake by including the scope

I guess it was Nat's comment :-)

> parameter in the initial request to the token endpoint. It seems that when
> you are replacing the code for an access token, the scope is not listed as a
> legal parameter.
>
> The initial authorization request MUST include all scopes that the client
> intends to use; in order for the provider to ask the user for permission
> when it has the user present (front-channel).
>
> When the provider issues a token the first time; it may select which scope
> the token has; typically it can be a 'openid-session' token, or a
> 'openid-userdata' token. Notice that in real life deployment I would assume
> that clients would ask for other scopes as well; and the provider may select
> to issue individual tokens or multi-purpose tokens.
>
>
> If the client receives a token that is valid in a subset of the scopes in
> the authorization request, it should use the refresh token to obtain tokens
> for the remaining scopes. OAuth section 6.
>
>
> I think there is a basic requirement to be able to get the id_token to the
> RP via the redirect response, so it can start rendering a page before it
> makes the subsequent calls to the token and user-info endpoints.
>
> I assume contacting the user info endpoint also add latency. Have you

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.

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

This
> will save latency, and make the user info service and the check session
> service much more consistent; also it will move you further away from
> OAuth.
> If you would like to be more true to OAuth, and at the same time would like
> to save latency, there also are alternatives: you could make the OP issue an
> short-lived access token with multiple scopes (both openid-session and
> openid-userdata), and the client can optionally use the refresh token to
> obtain a long-lived single-scope openid-userdata access token that may used
> for offline user data updates, and de-provisioning. In addition you could
> merge the check info and user info endpoints to a single OpenID Connect
> Service Endpoint, that would support delivering both user data and session
> data, if requested and an appropriate scoped access token were used.

You sound like you are tracing our history.
When we switched from returning OpenID Assertion from the token
endpoint and created UserInfo endpoint, we did return what we know of
now as id_token from the user info endpoint. So that is OAuth proper.
Actually, my slide decks stops there.

Then, some optimization for latency and security consideration came in
and now we have separate id_token.

The latency problem, I described above.

The security characteristics is that the token endpoint MUST NOT
return id_token more than once, 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. 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.
Apparently, scope alone does not work. Perhaps if we impose some
characteristics on the 'state' parameter, we can achieve it, but it
again is a departure and complication from OAuth 2.0.

>
> I fully understand that the timing is probably the worst to propose a major
> spec revision - I wish I joined the list a year ago. The problem is that the
> more I think of it, the more obvious it becomes to me that being more inline
> with Oauth would make a lot of things a lot simpler, and I think I would run
> into sleeping troubles if I had refrained from expressing the ideas - so I
> hope you apologize me... Discussing, and arguing pro and con the current
> spec is also a way for me to better understand the spec and the reasoning
> behind it. Understanding the spec and the reasoning behind it is crucial for
> me to continue my work.
> Andreas



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