[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.
>> 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.
>>>> 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
>>> The id_token can be statically validated, the CheckSession is a
>>> convenience mechanism for those who don't want to implement static
>>> 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.
>>>> On Mon, Aug 22, 2011 at 12:31 PM, Breno de Medeiros <breno at google.com>
>>>>> 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
>>>>>> 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.
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
More information about the Openid-specs-ab