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

John Bradley ve7jtb at ve7jtb.com
Thu Feb 2 19:41:22 UTC 2012


He mixed up two separate issues.  One is a change to Facebook's privacy (not for us to comment on),  and one that was technical.

That Facebook chose not to use refresh tokens.   
I commented that I don't know why thay chose to invent a new way to refresh tokens.   

I mostly just want to understand if they know something we don't,  not that adding new protocol endpoints is against the spec.

Though it probably won't contribute to interoperability of clients.  (if that is a goal)

John B.
On 2012-02-02, at 4:13 PM, Anthony Nadalin wrote:

> 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] 
> Sent: Thursday, February 02, 2012 10:12 AM
> To: Anthony Nadalin
> Cc: Mike Jones; 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> 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] On Behalf Of Mike Jones
> Sent: Thursday, February 02, 2012 9:50 AM
> To: 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
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> _______________________________________________
> Openid-specs-ab mailing list
> 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/a4c61665/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120202/a4c61665/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list