[Openid-specs-ab] Lite Draft 9

Breno de Medeiros breno at google.com
Mon Aug 22 20:04:21 UTC 2011

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

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.


More information about the Openid-specs-ab mailing list