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.
Related
I am using a mix of a browser (Xamarin webview; to initially login and getting an access token that expires in 1 hour) and httpclient (to access my webapi endpoint). When the token expires I request a new one using the /connect/authorize endpoint using a httpclient (with the cookies copied from the webview) to get a new access token.
This works alright as long as the cookies aren't expired.
I've set up identity server to have a sliding expiration of 1 day on the authentication cookie (CookieOptions: ExpireTimeSpan/SlidingExpiration). I thought that this would result (besides getting a new valid token) in receiving new cookies on every request to the authentication endpoint, effectively keeping me logged in. The problem is that the expiry of the initial cookie that I received when logging in using the webview is used. So no matter how many times I access the authorization endpoint, I'm still logged out after a day and I can't get a new token from the authentication endpoint anymore.
Assuming I'm not completely taking the wrong approach, what requests should get me updated cookies (IdSvr? IdSvr.Session? which do I need anyway?) with a new expiry date, so I stay logged in to IdentityServer?
Note: I did take a look at refresh tokens, but these aren't available for implicit flow. And I think I need implicit flow in my case because I shouldn't save a client secret in a distributed Xamarin app. Using the cookies seems like the best alternative.
Note to self (and others): the authentication cookie is the one that's important. For the record: that's the idsrv cookie.
Then the thing that confused me during testing: calling the /authorize endpoint will only return a new authorize (idsrv) cookie when at least half the expiration time has been passed.
This surprises me a bit, because that would mean that:
8:00 log in with sliding exp of 4 hrs (expire time: 12:00)
9:59 request to /authorize endpoint (expected new expire time: 13:59)
12:01 request to /authorize again
The 12:01 request would fail miserably, because the 9:59 call did not get me an updated cookie...
Had I made de second request two minutes later at 10:01, I would have gotten an updated cookie with expire time of 14:01.
Conclusion: sliding expiration seems only be sliding when half the expiration time has passed.
I am using JWT to authenticate with the Box API because I do not want my users to have to explicitly log in with their credentials (as you have to with OAuth2).
My issue is that the User Access token is only valid for 60 seconds.
So, does that mean that each time I make a request to the Box API (e.g. - iterate through some folders to find a specific file) I need to request a new User Access Token to ensure that it is still valid?
From my understanding there are no refresh tokens with JWT, so it seems this is the only solution ?
60 seconds is a very short amount of time. I don't want to have to keep track of time of each request, so it seems the only other option is to have to re-create the token for each API request. This seems ridiculous.
My issue is that the User Access token is only valid for 60 seconds.
Box JWT access tokens are valid for roughly 60 minutes. When you get a JWT access token the expires_in property will tell you exactly how long the token is valid, in seconds. In the example below, the token will expire in 4169 seconds, or ~69 minutes.
{
"access_token": "mNr1FrCvOeWiGnwLL0OcTL0Lux5jbyBa",
"expires_in": 4169,
"restricted_to": [],
"token_type": "bearer"
}
I don't want to have to keep track of time of each request, so it seems the only other option is to have to re-create the token for each API request.
Instead of keeping track of the epxiration time, you can make API requests until you receive a 401 response, then get a new access token, and finally then retry the failed request(s). Both options require coding effort. Fortunately some of the SDKs will do it all for you.
I have application that continuously running in background. The app uses UCWA REST api. After authentication I get OAuth token and some expiration time. Authentication docs say "The lifetime of a token is eight (8) hours for authenticated users. The client application should monitor the expiration time and refresh the token as required".
So, when is it required to refresh token? What expiration time should I have in reserve when starting refreshing token? 1, 10 or 60 minutes? What are OAuth best practices?
The response from ticket service will provide the user with the OAuth token, type of token, and an expiration value. This value is measured in seconds which means you can divide out minutes (60) or hours (3600) to get a value that you can expect requests to start failing with 401 Unauthorized. Monitoring is most useful when the application is using anonymous meeting join because the token expiration is much shorter, ~1 hour, and it is the only authentication mechanism to directly offer renewing a token.
This leads to two potential approaches:
If using anonymous meeting join
Check expiration value found in authentication response and start a timer less than the expected value (maybe 1-3 min less)
When timer expires refresh the OAuth token
If not using anonymous meeting join
Send requests until a 401 occurs
Check response headers for WWW-Authenticate and send another authentication request to get new token
Re-issue request with new token
It is better to wait for the 401 to come before taking action to refresh the token in a non-anonymous meeting join scenario.
is there a way to get longer token expiration time, or some kind of "permanent" token for client application ( Similarily as in DropBox API's)
SInce there seems to be problems with resumable upload to google drive when token expires, this could help in this situation ?
or is there just a way to define the token validity time to be bigger than 1 hour
br. Jarno
No accessTokens are only good for 1 hour. But you have a refreshToken that was returned along with your accessToken. You can use that to get a new AccessToken when the first one has expired.
Options:
Test either the expire time to see if its getting close to expireing and get a new one before it expires.
Wait until you get the error that says it has expired. Then request a new AccessToken
Personaly I like to get a new one 5 minutes before my AccessToken expires then I avoid an error from the google servers.
I ask for a Facebook access token with deprecate_offline_access turned on, and I get following response:
access_token=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&expires=5183977
Does anybody know, what "expires" parameter means? It's value is not timestamp...
I would like to know when the token expires, how could I do this?
Thank you.
The "expires" parameter is just the time remaining from the time of request until the expiration time. It should be read as "expires in 5183977 seconds from time of request".
5183977 seconds = 59.9997337962963 Days.
and answer to your last question 'what will I get if token is expired? will I get exception or just expired=0?'
you will get notification before token expire. If it is already expired (for mainly different reasons explained in facebook developer documentation) you have to re0auth the app and have to get new access token which will be again valid for next 60 days.