Can anyone say if following the instructions in the section entitled as per above in
https://developers.facebook.com/docs/facebook-login/access-tokens/expiration-and-extension
allows long lived access tokens to be refreshed daily?
For the last two months, I've been generating a new long lived token each day, but today I got an expiration error message. I am definitely generating a new token each day, but does this token expire 60 days from its creation?
Many thanks
I found a way round this.
In response to your questions:
(a) I have a script that runs daily and that makes calls to the Facebook API. The reason why I want to create a new long lived token each day is because I do not want to keep track and see if I am near expiry
(b) It is possible to create a long lived token from a long lived token as per https://developers.facebook.com/docs/facebook-login/access-tokens/expiration-and-extension#long-via-code under the section 'Generating Long-Lived User Tokens from Server-Side Long-Lived Tokens'
Related
We are developing an integration with DocuSign. We use embedded signing and JWT authentication.
We received information from DocuSign Partner Solutions team that in JWT authentication, the expiration of the access token can be set by us to a long period of time.
based on that information, I designed the solution so we manually do the JWT authentication flow: get user consent, generate JWT, set expiration to one year and use it to obtain a long expiring access token.
now we went out of sandbox to production. We are testing the solution against a 30 days trail production account. We got user consent. I generate JWT and set expiration to various periods (one day, one month, one year) but I always get an access token that is good for one hour only.
PS, I went through the official documentation which states this about JWT exp property:
Defaults to one hour from the value of iat, and cannot be set to a greater value.
I wanted to know if anyone was able to generate long expiring access token out of JWT in DocuSign
The maximum grant time for access tokens received via the DocuSign OAuth JWT Grant flow is 1 hour.
The maximum grant time for access tokens received via the DocuSign OAuth Authorization Code Grant flow is 8 hours.
Good news for your application is that it is easy to obtain a new token via the JWT Grant flow: just re-run it within your app when the token that you have is about to expire or has expired.
No interaction with the user is needed since they have already provided consent (a one-time operation).
Note that the JWT Grant flow can fail, especially if the user has withdrawn their consent. Be sure to test this situation.
I'm sorry that you were given incorrect information.
I'm beginning a Single Page Application, and I'm using JSON Web Tokens to Authenticate client side (JS Client with Server API).
In my app, user provides credentials (app auth, facebook, google) and then server checks for user existence and returns a token.
Client JS adds token to each request in order to use the Server API.
When token gets issued, it has an expiry time and a max refresh time. If a set a short expiration time for the token and a "good" max refresh time I get into having to know when to refresh tokens. Best approach I've found so far, is to check on client when the token is being expired (5 minutes before) and then issue a refresh request. Then I'd get a new token. This could be done till max refresh time is reached. Then, user should have to reauthenticate.
Another approach I've seen, is that on server, if token is nearly or has just expired, it gets auto-refreshed and returned to client (which has to detect token change and store it)
But... what is the difference between this and having a single token that is long lived?
Is having a short lived access token which can be renewed with a refresh token tons of times better than having a single long lived access token?
The primary reason to use a short-lived token is to defend against session hijacking, when an adversary, through one method or another, steals session credentials (in this case, the token) and acts maliciously in the victim's session. The shorter-lived the token, the less time the attacker has to carry out whatever malicious activity they have planned.
Just read about the offline_access permission being removed and therefore having the new system of "extended access tokens".
My problem is that i'd like to save the expiration timestamp to take care that the saved access tokens are always valid, but the Documentation doesn't provide a time that the extended token is valid for.
Does anyone have more information regarding that?
It'd be interesting to know if they long-living tokens are valid for days, weeks or months.
When you use the new endpoint which is explained in the post you linked to:
https://graph.facebook.com/oauth/access_token?
client_id=APP_ID&
client_secret=APP_SECRET&
grant_type=fb_exchange_token&
fb_exchange_token=EXISTING_ACCESS_TOKEN
The response will have this form:
access_token=xxxxx&expires=yyyyy
The expires param is what you are after I believe.
Long lived tokens are good for 60 days, and you can check tokens (for debugging) with the Debug Tool which will tell you everything you need to know about the token.
Edit
A few more things.
The "expires" parameter gives you the time left until expiration, so the expiration time is timestamp of now + expires.
It's easy to check this with out the need to do any development, just create a fb app (if you don't have one), go to the Access Token Tool and copy the user token from your app, then using curl make a request to the new endpoint.
As for extending the long lived tokens, there's no way to do that, you'll need to re-authenticate the user after that, as it states in the same post:
If you pass an access_token that had a long-lived expiration time, the
endpoint will simply pass that same access_token back to you without
altering or extending the expiration time
Another point is that you can get long lived access tokens by using the Server-Side authentication flow, but those too can not be extended.
It only returns back access_token not
access_token=xxxxx&expires=yyyyy as mentioned above.
Atleast that is what I can see...
I am a little confused about calculating the time until the access token expires.
I am using server authentication (http://developers.facebook.com/docs/authentication/server-side/).
When I get the authentication code from the Facebook's request to my redirect URL, I send an authentication request back to Facebook and I get the access token along with 'expires' parameters, lately I could see that the expires is a long value that represents the time in seconds until the token expires. For some reason I think it used to be time in miliseconds.
Can I assume that the expiration time is now + expires (in seconds) - it seems to me too long (about ~5109691 seconds) - does it make sense?
Thank you for your help.
Server authenticated access tokens are valid for two months.
The value you are receiving is correct.
Edit:
https://developers.facebook.com/roadmap/offline-access-removal/
Read the 'Server-side OAuth Developers' section.
I am working with Oauth2.0. In that i could able get the access_token and instance_url. Is there any expiry time for these two.
Can I store them and use it for all my REST calls without getting the new access_token and the instance_url. Is it possible for me to use it for long hours or even days.
The access token is only valid for the length of a session (as defined in the Salesforce Org's settings — I believe the longest this can be is 8 hours without activity), as it's actually a session ID, that said, you should also be given a refresh token. The refresh token has a much longer lifetime and can be used to authenticate the user once the session has expired, without them having to enter any credentials — this allows you to do it in the background without them even having to concern themselves with the login process.
model metrics do a good job of explaining the token flow here.