[Openid-specs-ab] Lite Draft 8

Breno de Medeiros breno at google.com
Thu Aug 18 22:09:12 UTC 2011


We may want to write a theoretical protocol that requires HTTPs.

It's unlikely people will be able to login to their favorite news site
using it. My guess is that this will be extensively used in non-HTTPs
contexts, unless it fails altogether as a spec.

Planning for success means that while we strongly encourage HTTPs, we
should have mitigation measures for non-HTTPs case.

On Thu, Aug 18, 2011 at 15:05, Anthony Nadalin <tonynad at microsoft.com> wrote:
> 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
>
>
>
>
>



-- 
--Breno


More information about the Openid-specs-ab mailing list