[Openid-specs-ab] Lite Draft 9

Nat Sakimura sakimura at gmail.com
Wed Aug 24 23:45:25 UTC 2011


That further increases the length of the id_token.

What Nov is making a point on is that, from a developer point of view,
since usual access_token and id_token are very different in its
characteristics, the argument that treating id_token as an
access_token to the check session endpoint makes the life for the
developer simpler because one can reuse OAuth library is simply not
true.

In fact, it would pose a significant challenge in some cases, so it is
better to make id_token as a parameter separate from an access_token
for the check session endpoint.

Nov has been providing Rack-OAuth2 library for sometime, which is
being used in many places, so he may have some point as a developer
feedback.

=nat


On Thu, Aug 25, 2011 at 2:56 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
> Yes that is what the OP check session endpoint is supposed to do.
>
> Google has however added a bit of a twist on the last call.
>
> They are proposing that a hash of the access token be included in the id_token.
> The idea is that that allows a RP to know if the received access token relates to the id_token.
>
> That change would require the check session endpoint to take the user-info access token as a parameter, so that it can check the hash for the client.
>
> This is still being discussed, but could cause a change in the current Check Session endpoint.
>
> I am inclined to leave the check session endpoint as is, and make the client calculate the hash if they want to.
> This correlation check between the two tokens is not required for the code flow, only the token flow to prevent cut and paste.
>
> John
> On 2011-08-23, at 7:03 PM, nov matake wrote:
>
>> Aren't you talking about RPs?
>>
>> If so, sorry for the confusing.
>> I'm on OP side now.
>>
>> This is the actual OP check session endpoint code in Ruby.
>> I just verify signature and return extracted JSON here.
>> https://github.com/nov/openid_connect_sample/blob/master/lib/check_session_endpoint.rb
>>
>> On 2011/08/24, at 2:10, Breno de Medeiros wrote:
>>
>>> On Mon, Aug 22, 2011 at 19:00, nov matake <nov at matake.jp> wrote:
>>>> Since there is significant difference in its length between OAuth 2.0 access token and id_token,
>>>> I personally doesn't want to store them in the same table in DB.
>>>>
>>>> And I do access token validation in middleware layer in my Rails app, it's not so simple to lookup different token tables based on the requested endpoint.
>>>>
>>>> So handling id_token as access token doesn't seem simpler solution for me.
>>>
>>> The intended usage is to handle id_token as a cookie. You may rely on
>>> static validation to treat as a stateless credential or if you have
>>> session storage, you can store a shorter hash of the id_token to
>>> prevent re-validation everytime.
>>>
>>>>
>>>> Plus, in the current format of access token response, there are no information about the token type of id_token.
>>>> When the type of access token is Bearer, the type of id_token is always Bearer too?
>>>> What happens when the access token is MAC token or others?
>>>>
>>>> If we use id_token as access token, I prefer defining new access token type. (eg. use IdToken as Authorization Scheme)
>>>>
>>>> --
>>>> nov matake
>>>>
>>>> On 2011/08/23, at 5:21, John Bradley wrote:
>>>>
>>>>> Treating the id_token as the access token for the Check session endpoint, makes it clear what you need to do with it.
>>>>> We can invent a new unauthenticated API, but I think that is more complicated.
>>>>>
>>>>> I have had other providers talk about delivering multiple access tokens from a single request.
>>>>> I suspect that it will not be uncommon with OAuth 2.
>>>>>
>>>>> There are lots of reasons why a IdP might want to use different access tokens fro different services. especialy if they are stateless.
>>>>>
>>>>> John
>>>>> On 2011-08-22, at 4:04 PM, Breno de Medeiros wrote:
>>>>>
>>>>>> On Mon, Aug 22, 2011 at 13:00, Allen Tom <allentomdude at gmail.com> wrote:
>>>>>>> Hi Breno -
>>>>>>> I don't have much first hand experience with FB's signed_request, but my
>>>>>>> understanding is allows FB to return a signed response to an app, so that
>>>>>>> the app knows that it came from FB.
>>>>>>
>>>>>> Actually, signed_request is intended to be the identity assertion so
>>>>>> that apps can login users to their sites. The alternative is to make a
>>>>>> call to their version of the user info endpoint. In other words, the
>>>>>> FB Connect design is nearly identical to this.
>>>>>>
>>>>>>> https://developers.facebook.com/docs/authentication/signed_request/
>>>>>>> The docs don't say that there are two Access Tokens, instead the Access
>>>>>>> Token is a signed parameter contained within the signed_request.
>>>>>>> My concern regarding the id_token and the CheckSession API is that it could
>>>>>>> be confusing to tell developers that the id_token is an Access Token, but
>>>>>>> only for the CheckSession API. All other endpoints use the regular Access
>>>>>>> Token.
>>>>>>
>>>>>> The id_token can be statically validated, the CheckSession is a
>>>>>> convenience mechanism for those who don't want to implement static
>>>>>> validation.
>>>>>>
>>>>>> I think the CheckSession endpoint is morally an
>>>>>> non-authentication-required endpoint that cracks open the id_token.
>>>>>> Passing the id_token instead of the access_token may make it easier to
>>>>>> re-use code.
>>>>>>
>>>>>>> Allen
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Aug 22, 2011 at 12:31 PM, Breno de Medeiros <breno at google.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Mon, Aug 22, 2011 at 12:05, Allen Tom <allentomdude at gmail.com> wrote:
>>>>>>>>> I think it might be confusing to developers to have multiple access
>>>>>>>>> tokens.
>>>>>>>>> I don't think I've seen any other Connect/OAuth
>>>>>>>>> type implementations that
>>>>>>>>> return multiple access tokens. Are there any examples out there?
>>>>>>>>
>>>>>>>> Yes. Facebook Connect uses signed_request as the id_token.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> --Breno
>>>>>
>>>>> _______________________________________________
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> --Breno
>>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


More information about the Openid-specs-ab mailing list