[Openid-specs-ab] Lite Draft 8

John Bradley ve7jtb at ve7jtb.com
Thu Aug 18 20:47:39 UTC 2011


One of the early design decisions was to not mess with the access tokens people are currently using.

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

The arguments against that were breaking existing API 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.

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

John
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

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


More information about the Openid-specs-ab mailing list