[Openid-specs-ab] Lite Draft 9

Breno de Medeiros breno at google.com
Tue Aug 23 17:10:31 UTC 2011


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


More information about the Openid-specs-ab mailing list