[Openid-specs-ab] Lite Draft 9

John Bradley ve7jtb at ve7jtb.com
Wed Aug 24 17:56:39 UTC 2011


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
> 

-------------- 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/20110824/7b86462f/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list