[Openid-specs-ab] Facebook changes offline access

John Bradley ve7jtb at ve7jtb.com
Thu Jan 26 15:38:41 UTC 2012


I couldn't decide reading it if with the code flow you can't use the new endpoint, because you need to get code again.

After reading it a number of times, I think they are saying that you can use it, but not with a access token granted before the change.
You must get the user to login once to get code then you can exchange that for a 60day token and subsequently triad that for a refreshed token.

On the other hand a cron job not being able to extend the token automatically doesn't fit with that interpretation.

Why a token bootstrapped with the code flow would have more restrictions than one from a token flow is not immediately obvious to me.

There may be some backside state that prevents the token from being extended if the user is not logged in.

The important thing is that they are extending draft 10 of OAuth 2 rather than adopting the methodology from the soon to be final OAuth spec that we have been tracking.

I admit that this may be better than issuing non-expiring access tokens via the token flow.

To address the use case the OAuth spec was changed to allow for return_types to as for 'code token' so that you could get a access token in the front channel and a refresh token in the back channel.

In thinking about token lifetimes and refresh,  I am coming to the conclusion that we may need to say more in the spec to achieve reasonable interoperability for clients.

John 

On 2012-01-26, at 11:27 AM, nov matake wrote:

> My understanding is
> 
> In implicit flow
> * default expiry is short (same with current spec)
> * within several minutes the token established, its expiry can be extended using client authentication and "fb_exchange_token" grant type.
> 
> In code flow
> * default expiry is longer (60 days)
> * same token can be returned if expiry doesn't change from the previous token
> 
> I assume they want to require client authentication even for developers using FB JS SDK (= implicit flow).
> 
> ps.
> They are saying as below in "Server-side OAuth Developers" section.
> 
> Note:
> The user must access your application before you're able to get a valid "authorization code" to be able to make the server-side oAuth call again.
> Apps will not be able to setup a background/cron job that tries to automatically extend the expiration time, because the "authorization code" is short-lived and will have expired.
> 
> 
> On 2012/01/26, at 22:41, John Bradley wrote:
> 
>> https://developers.facebook.com/docs/offline-access-deprecation/
>> 
>> It looks like they are creating a new endpoint for extending access tokens rather than using refresh tokens.
>> 
>> My read of it is that developers )will now get offline access without asking.  They just need to refresh the access token every 60 days.  
>> 
>> The documentation is typical of Facebook so the actual operation may be different. 
>> 
>> Using the 'code token' return type with a refresh token would have been OAuth 2.0 compliant.
>> 
>> I expect the media will jump on the privacy issue.
>> 
>> John_______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 

-------------- 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/20120126/eef7c357/attachment.p7s>


More information about the Openid-specs-ab mailing list