[Openid-specs-ab] Lite Draft 8

Johnny Bufu jbufu at janrain.com
Thu Aug 18 21:48:05 UTC 2011


On 11-08-18 01:47 PM, John Bradley wrote:
> One of the early design decisions was to not mess with the access tokens people are currently using.

What are the features of the tokens people are currently using and are 
relying on?

> I originally wanted to make the access token a JWT so that a single token could be used for both.

Why would a JWT access token not work if it were treated as opaque by 
existing and/or lite clients?

> The arguments against that were breaking existing API

I'd like to understand this part, if anyone could spare some cycles to 
explain. Again, the proposal is built around a JWT access token that can 
be treated as opaque by clients that wish to do so.

> and a desire by people who do want to pass scope inside the token to separate the delegated access scopes from the session management info.
> They didn't want both in the same token.

My proposal seems to accomplish this, by having servers identify the 
appropriate grant by the composite key made of token and endpoint. Am I 
missing something here?

> Changing to a single token effects session management and the rest of the specs  that is a huge change.

If the JWT access token can be treated as opaque by clients accessing 
the check session endpoint, how does that significantly affect session 
management?

A single token that keeps the features of both previous tokens would be 
simpler. The specs are in a state of flux anyhow, with the rather 
confusing organization and the inconsistencies between them, coupled 
with the ambiguity around the central piece, the ID token.

Johnny

> On 2011-08-18, at 3:46 PM, Johnny Bufu wrote:
>
>>
>> On 11-08-16 04:31 PM, John Bradley wrote:
>>> The two tokens have potentially different scopes and lifetimes.
>>>
>>> There are good reasons for separating resource authorization from session authentication.
>>
>> An OAuth token is, conceptually, an identifier for a grant that the server keeps in its database.
>>
>> Rather than emitting two different tokens, the server could associate the two grants with a single token, and service it differently based on the endpoint the token is presented at:
>> - the sorter-lived, one-time use grant for the check session endpoint
>> - the longer-lived, multiple-use grant for the userinfo endpoint
>>
>> This single token would be a short identifier, not a heavy(er) JWT, suitable for lite clients.
>>
>> On 11-08-17 07:35 PM, John Bradley wrote:
>>> We did discuss using a JWT for the access token so that it could do
>>> double duty.
>>> Some people like Sales Force have existing code for there access tokens
>>> so they don't want to change that.
>>> Another issue is token size, making the session token carry all of the
>>> scope information for the user-info and other endpoints may make the
>>> token too large to be practical.
>>>
>>> It would also be more complicated for the RP to get right, than keeping
>>> the session and access grant tokens separate.
>>
>> Full clients wanting a signed JWT for optimization could indicate this in the authorization request. There shouldn't be much of a problem for servers to use the JWT as an identifier / access token for the userinfo grant, but full-clients' life should be made easier by including an equivalent but shorter userinfo access token in the JWT payload.
>>
>>
>> Thoughts on this proposal? I'd like to find out if I missed anything that would prevent it from covering the use-cases I've seen brought up on the list recently.
>>
>>
>> Johnny
>


More information about the Openid-specs-ab mailing list