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...
Related
I have a question on "make the browser send out a request to exchange for a new token at the sixth day. Accordingly, on the server side, create a restful API named /token/extend which will return a new token if given a valid token."
Let's assume that I implement this concept. When token is about to expire, we will generate new valid token if old valid token is provided.
Now, let's assume, Hacker gets the token. He uses this token to communicate with APIs. Hacker communicates for 6 days. On 6th day, our "/token/extend" API will generate new token for him so he can communicate for another 6 days, and probably forever. Will this situation occur? or Am I missing something here?
The general way you would force your users to obtain a new token after 6 days would be by simply setting the exp field (expiry) in the claims of the JWT to expire after 6 days. The exact mechanism by which users would use to obtain a new token depends on your implementation.
The most basic implementation would be to just let the incoming request on the sixth day to fail, forcing the consumer of the API to redirect to the login page. From there, the user would have to login again to obtain a new valid JWT. A more elaborate method would use refresh tokens. With this approach, when the user first logs in, he would receive an authentication token with a 6 day expiry (as before), but would also receive a refresh token which would expire a little bit later. On the sixth day, when the user tries to access a service, the request would again fail. However, in this case, the consumer (e.g. a website or mobile app) could take the refresh token and request a new access token under the hood. This would be a more seamless way of handling the mandatory 6 day expiry. Note that with the refresh token approach, the user might never know about the 6 day expiry.
Regarding your concerns about hackers obtaining other people's tokens, you should mostly just forget about this. If someone stole your wallet, there is all sort of havoc he could do to you, e.g. using your credit cards, stealing your identity, etc. The same could happen with a stolen/sniffed JWT. The best practice here is to just make sure you are using two-way SSL for all communication, and also encourage your users not to use your services in places like Internet cafes.
I'm learning making API Requests from a mobile app.
An API that I am using, returns an access_token, expires_in and refresh_token when making a login request.
I'm trying to understand the whole logic behind the access token idea, been looking all over the internet and cannot find a good example nor a good explanation.
As far as I am aware,
The best method for making API requests is:
1) Store the expires_in internally on the device
2) On every request first check if the token is expired
3) If so, then request a new one using the refresh token
4) Otherwise make the request
Is this right?
Your flow is basically correct.
If it is a JWT token, you can decode it. Inside you can find some properties, check here.
What you can do is use the iat property of the token, this contains the time when the token was issued (you can't rely on the received date from the WS) add the expiration time to that date, this will be the expiration date.
If you are using Alamofire is pretty easy, there are 2 protocols:
RequestAdapter
RequestRetrier
By using a combination of the two can you easily refresh your token, in the request adapter you can throw an error if the token is expired, in the retrier you can intercept this specific error and make a refresh token request.
It is explained here.
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.
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.