[Openid-specs-ab] Lite Draft 8

Anthony Nadalin tonynad at microsoft.com
Thu Aug 18 22:05:29 UTC 2011


In the current draft only 3.2.2 mentions HTTPS and does not state that it's mandatory

-----Original Message-----
From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Johnny Bufu
Sent: Thursday, August 18, 2011 2:56 PM
To: Breno de Medeiros
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Lite Draft 8


On 11-08-18 02:41 PM, Breno de Medeiros wrote:
> There's also a concern with HTTPs support (or lack thereof by some 
> clients). An id_token that is used as a session cookie and leaks 
> through an unprotected channel can presumably cause less damage than a 
> full access_token might.

Which parts of the protocol are not required to use HTTPS?

> Regardless of HTTPs support, it's usually a good idea to treat cookies 
> and API access tokens as different beasts for security reasons, and 
> the id_token is functionally a session cookie for the client.

The single token would be used one time as an access token for the check session API/endpoint, and the response from there as the actual cookie value/session identifier. Would this now be ok?

Johnny

> On Thu, Aug 18, 2011 at 13:47, John Bradley<ve7jtb at ve7jtb.com>  wrote:
>> 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
>>
>>
>
>
>
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab






More information about the Openid-specs-ab mailing list