I'm not sure if this is just exclusive to google API's and this is not plausible, but in the OAuth google developers playground, one can give in an access token and receive a refresh token which never expires. I for one have done this and implemented it in my code, but I was wondering, is there such a thing for an Instagram access token?
With the recent changes taking place in there api (2016 ->), I have not found any questions asking this as before I believe the token did not expire.
Thank you and sorry if I seem to be missing something obvious.
From the doc:
Access tokens may expire at any time in the future.
Even though our access tokens do not specify an expiration time, your app should handle the case that either the user revokes access, or Instagram expires the token after some period of time.
So in short, today, tokens do not expire, but they could in the future, so your app must handle the case if one day they expire.
Related
My Access Token is expired after 1 hour and videos are not uploaded in to you-tube due to invalid access token and every time asking for authentication.
How to reactivate existing token or refresh access token.
You schould use long-lived token. There are several methods to get it, but everything is well described here:
Facebooke developers extending tokens
If you want more precisious answer please write in which language are you trying to do that.
I am working on a Google Drive App.
What is the lifetime of a Refresh Token? I have read that it lasts till until it is revoked. However, I also read somewhere that if your app is not used for 60 days, then the refresh token expires. Is this true ?
Also, who revokes the refresh token, is it the the user or in my case Google itself after a certain period of time?
I've not heard of a refresh token expiring after 60 days inactivity. Do you have a link that claims so?
The token can be revoke by the user or by your application.
I think, as per my study for the google drive file access using the refresh_token. The refresh token stays for around 6 months and then it we have to revoke it at that time when it gets expired. Google api's documents are nice and easy bit somehow lacks the way to use it.Just a thought, and once stuck got to search many place and less response to issues.
Every time I read https://developers.facebook.com/roadmap/offline-access-removal/, I'm left more confused than the time before. I'm looking for some clarification on some items under scenarios 3 and 4 (server-side apps and client-side apps)
For server-side apps, it states "If the call is made while there is still a valid 60-day access_token for that user, the returned access_token from this second call may be the same or may have changed, but in either case the expiration time will be a fresh 60 days."
What is "the call" that is referred to here?
Is it the same exchange of an authorization code for the access token that takes place during the initial OAuth flow?
Or is it the endpoint call described under the client-side section to freshen the token to 60 days?
If it's the former, then where does the authorization code come from when trying to renew the token?
Is it the same authorization code from the original callback or do I have to go through the authorization flow again?
In short, can a server-side app keep freshening the life of a 60-day token and, if so then how?
Regarding client-side use, the document indicates that the client must make that endpoint call passing in (among other things) the application's client ID and client secret.
My interpretation of "client-side" may be wrong, but I'm thinking in terms of a JavaScript-based client running in a web-browser.
If that's what Facebook has in mind here, then should the JavaScript code really ever know about the client secret? (It won't be much of a secret if it's sent to the client.)
Even then, it indicates that 60-day tokens cannot have their life extended and that a new 2-hour token must first be acquired and used to get a 60-day token. This is under the client-side portion of the document, but does this rule apply to server-side 60-day tokens, too? If not, then I ask again: How do I freshen the life of a 60-day token on the server-side?
Finally, the question that has been burning in my mind for some time: Why has Facebook adopted this strategy and not adopted the refresh token as defined in the OAuth 2 specification (a specification that Facebook is helping define)???
EDIT: Further thoughts/questions after re-reading the document again:
At the beginning it says "a long-lived expiration time that can be renewed each time the user revists your app". My initial assumption is that the way to renew it would be to make a call to the endpoint later in the document. But, aside from the fact that the endpoint is described under the "client-side" heading, it also states "Please note, the endpoint can only be used to extend the short-lived user access_tokens. If you pass an access_token that had a long-lieved expiration time, the endpoint will simply pass that same access_token back to you without altering or extending the expiration time." (The typo on "long-lieved" is from FB's own documentation.)
Okay, so if that endpoint cannot be used to renew the expiration time (and my own attempts to renew a long-lived token with that endpoint prove this out), then how can I renew the expiration time on a long-lived token each time they visit my app?
Is there no one who understands how this is supposed to work?
After reading Facebook's doc (like for the 5th time) and with the help of this question/answer this are my conclusions.
What is "the call" that is referred to here?
It referres to the OAuth call to get an access token.
Is it the same exchange of an authorization code for the access token
that takes place during the initial OAuth flow?
Yes, I believe it's that flow.
Or is it the endpoint call described under the client-side section to
freshen the token to 60 days?
No, that endpoint is only valid for short-lived access tokens.
Is it the same authorization code from the original callback or do I
have to go through the authorization flow again?
You've to go through the authorization flow again.
how can I renew the expiration time on a long-lived token each time
they visit my app?
Long-lived access tokens cannot be renewed using the client side endpoint. The user will have to reauthorize the app to get a new one.
According to Facebook documentation:
If the call (OAuth authorization call) is made while there is still a valid long-lived user
access_token for that user, the returned user access_token from this
second call may be the same or may have changed, but in either case
the expiration time will be set to a long expiration time.
Once the application is reauthorized you'll get a new expiration time. Facebook may return a new long-lived access token, so you should grab it and replace that information for the one you already had.
Conclusion:
Seems there's no way to renew a long-lived access token without user intervention. To get a new expiration time/access token they'll have to reauthorize your app. My humble advice is that should suggest the user to reauthorize it, a few days before the expiration date.
Also, this Facebook how-to can came in handy for checking expired access tokens.
what is the lifespan of an access token in the FB oAuth API?
Not the extended offline permissioning, just a normal access token?
If you don't specify the offline permission, then the token is only valid while the user is signed in to Facebook and only until the expiry that gets passed back to you passes. I think it is somewhere around 2 hours generally but I haven't verified it. You can find more information from Facebook's documentation.
http://developers.facebook.com/docs/authentication/
User access token expiry is returned when the access token is issued (you see it appended to the end of the access_token). It is currently 2 hours, but that is subject to change. The key thing to remember is that access token can become invalid for a number of reasons and you need to make sure that you are prepared to handle that case. See the how-to for this at: https://developers.facebook.com/blog/post/500
App access tokens have no expiry right now, but I expect that we are going to change that and you should also be prepared to handle the case where this token becomes invalid.
I need to download my Delicious bookmarks to a non-web application without constant user interaction. I'm using Delicious's V2 API (using oAuth) but the problem is it seems their access tokens expire after one hour.
I don't have any issues with redirecting the user to Yahoo for a one time authorization, but what is described here (http://developer.yahoo.com/oauth/guide/oauth-refreshaccesstoken.html) means I would have to refresh my access tokens all the time before they expire when the user is away.
Is this really the way they've done their oAuth implementation?
You only need to refresh the access token when they come to use the application again, not while they're away. You can pass the previously expired token and get a new one in return.
Is that a problem? You should only need to make an additional server-side call to refresh the access token if it expires (as long as the authorization itself has not expired, which should last longer, and would need user interaction when it expired).