[Openid-specs-ab] Lite Draft 9

nov matake nov at matake.jp
Tue Aug 23 02:00:01 UTC 2011


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.

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



More information about the Openid-specs-ab mailing list