[Openid-specs-ab] Facebook OAuth extension ruffles feathers, nixes user access permission

Anthony Nadalin tonynad at microsoft.com
Thu Feb 2 19:13:15 UTC 2012


I just find the article a bash on what is allowed by the OAUTH 2.0 specification, granted that short lived tokens may be better and recommended but long lived tokens are not disallowed.

> They made a new token endpoint that takes the client secret and the access_token and returns a long lived access token.
There is nothing in the OAUTH specification that disallows this

From: John Bradley [mailto:ve7jtb at ve7jtb.com]
Sent: Thursday, February 02, 2012 11:06 AM
To: Anthony Nadalin
Cc: Nat Sakimura; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Facebook OAuth extension ruffles feathers, nixes user access permission

Facebook has their own unique version of OAuth 2.0.  It is not compliant with any particular draft.   They have a token endpoint that is more OAuth 1.0.

They made a new token endpoint that takes the client secret and the access_token and returns a long lived access token.

I am assuming that OIC will use refresh tokens for that.

I was actually looking for similarities between the two profiles of OAuth 2.0 for another project when I noticed facebooks announcement to developers on the API change.

I mostly thought it strange because they do support both a 'code token' and a 'signed_request token'  response type like OIC that already has the required functionality.

They may have a good reason for doing it via a extension to OAuth 2.0 though I don't yet understand it.

I don't think it has any bearing on our work.

On the upside I did find their use of multiple response type is consistent with ours.

John B.

On 2012-02-02, at 3:22 PM, Anthony Nadalin wrote:


FB will be still standards compliant I bet, but not using an extension that has been through the standards process, BUT using an extension point that is part of the OAUTH V2 standard. Also this article talks about authentication mostly which OAUTH tries very hard to avoid (and leave that to HTTP)and only deal with authorization, so this article is misleading in that sense.

From: Nat Sakimura [mailto:sakimura at gmail.com]<mailto:[mailto:sakimura at gmail.com]>
Sent: Thursday, February 02, 2012 10:12 AM
To: Anthony Nadalin
Cc: Mike Jones; openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] Facebook OAuth extension ruffles feathers, nixes user access permission

I suppose the article is not talking about OpenID Connect at all but just questioning why they creat yet another way of extending the access token validity time while OAuth 2.0 has a defined way of doing it.

I can sort of understand it. Being not standard compliant to fragment is the market is a valid strategy for the largest player.

=nat via iPhone

On 2012/02/03, at 3:02, Anthony Nadalin <tonynad at microsoft.com<mailto:tonynad at microsoft.com>> wrote:
What FB does is their business, they have created an extension that serves their own business needs, it's not part of OAUTH (but seems to fit the extension model). Everyone is allowed to create extensions that they feel are needed. I believe that they feel that OpenID Connect is too complicated for them to implement thus they have gone their worn route.

From: openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net> [mailto:openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net>] On Behalf Of Mike Jones
Sent: Thursday, February 02, 2012 9:50 AM
To: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: [Openid-specs-ab] Facebook OAuth extension ruffles feathers, nixes user access permission

http://www.zdnet.com/blog/identity/facebook-oauth-extension-ruffles-feathers-nixes-user-access-permission/192?tag=mantle_skin;content

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120202/ae9f92b8/attachment-0001.html>


More information about the Openid-specs-ab mailing list