[Openid-specs-ab] Lite Draft 8
jbufu at janrain.com
Thu Aug 18 19:46:16 UTC 2011
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.
More information about the Openid-specs-ab