[Openid-specs-ab] Lite Draft 8

Johnny Bufu jbufu at janrain.com
Thu Aug 18 22:20:44 UTC 2011


On 11-08-18 03:00 PM, John Bradley wrote:
> We are only saying the access token for the Check Session is a JWT.

Do you have a pointer here? As far as I can see in Session Management 
draft 3 the JWT ID token only shows up in responses, so my proposed 
single access token should work for the check session requests too.

> A IdP can use any existing token type for the user_info and other endpoints.
>
> People don't want to be forced to use JWT for user_info as I understand it.
> A JWT would work but it may break existing IdP like SalesForce.

I still fail to understand how, if the JWT token is treated as opaque by 
clients.

Johnny

> On 2011-08-18, at 5:48 PM, Johnny Bufu wrote:
>
>>
>> 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