I have some questions about the access_token usage on server-side web apps.
How should I keep the access_token valid?
Is it possible to check it before making a request, or should I just try to make a request and renew it if error? Or maybe set up a cronjob that renews all the access_tokens?
The expires_in field, is it seconds? Can an access_token expire before this value?
How should I keep the access_token valid?
You can't. It will expire as sure as eggs is eggs. All you can do is get a replacement.
Is it possible to check it before making a request, or should I just try to make a request and renew it if error?
You can check it by referring to the expiration time(1), or try and catch the 401 exception(2).
Or maybe set up a cronjob that renews all the access_tokens?
Yep (3)
Congratulations, you've won a prize by enumerating all three access token refresh policies :-). As to which one should you use, it depends. You need to decide if speed, user experience, or network bandwidth matter most to you. By far the safest is to catch the 401, and refresh, because that deals with all eventualities. With that in place, you may decide to speed things up by doing a refresh after 3550 seconds.
The expires_in field, is it seconds?
Yes
Can an access_token expire before this value?
Good question. I'm going to say yes, if the user withdraws permission to the app. Otherwise no.
Related
Im wondering if anyone has any answers to this. If one follows the quickstart here:
https://developers.google.com/calendar/api/quickstart/go
we can get authorization from a user that allows us to do things with their calendar.
It seems the HTTP Client given back from the config handles calling the refresh token and keeping the client up to date.
First, as a side-question, does anyone know how long this is allowed to persist? I read in a doc somewhere that for unpublished apps/projects its 7 days, but it didn't specify a timeline otherwise. Is it indefinite or will this expire at some point (ie the refresh token runs out after 30 days). And is this avoidable at all?
now, the real question - if you take the service down entirely, ie for an update, and restart it, is there any way to opick up the authorization again? In the tutorial its writing a code to disk and reading as needed. In my case I just hold reference to the things I need in the application, so obviously when the service went down id have to reauthorize. I then tried writing the code to disk on a persistent volume and re-reading from that, but it doesnt get authorized - I guess because the new instance of the service has a new instance of the oauth config, and it wont accept the old code perhaps?
In any case, im wondering if anyone knows of a way to make this persist through ssytem restarts, or if the only real option here is to move the calendar service client to a small microservice on the side that we do not restart, and contact it from elsewhere as needed.
Thanks in advance!
The refresh token expiration is documented here. As you've noted, tokens expire in 7 days for projects in "Testing" status. Refresh tokens for projects in production last indefinitely, but there are some scenarios where they may get invalidated (user revokes access, token has not been used in 6 months, the account has over 50 live tokens, etc.). It's not mentioned but if you change your OAuth scopes you'll probably need to reauthorize as well.
This means that as long as you keep your refresh tokens and none of the invalidation conditions are met, you should be able to keep using them to get new access tokens even if your service goes down temporarily. But as mentioned in the documentation, you should anticipate the possibility that the token stops working and redirect the user to authorize again.
My guess is that in your case the refresh token stopped working for some reason (maybe the 7 days limit) and the application just tried to use the same expired token. The Quickstarts in Google's documentation usually handle the creation of the token file and how to reuse it, but they don't include the part where you have an invalid token and need to reauthorize.
References:
Google's OAuth2 Overview
OAuth2 for Web Apps
I have session timeout setting as 1 hours, and my initial access_token seems timeout around this time. This is excepted.
And after it timeout, i did token refresh and get a new access_token, then i observed this refreshed access_token seems not timeout in 1 hours, even 5~6 hours after, it still not expired.
So is there refresed access_token never expire? Can someone explain more about this?
Refresh token policy is managed from admin side usually and is different from the initial access token. From what you say the setting you have right now for Refresh token is probably 'Refresh token is valid until revoked'.
When you go to your Salesforce org go to Setup -> Manage Connected Apps - find the connection you are looking for and see what policy you have set. You can set it to expire in number of days, based on usage or Immediately.
I've integrated with Gmail OAuth and have it working pretty good. The only remaining issue is using the refreshToken to retrieve a new accessToken when it expires. I persist both of these in CoreData so I have easy access to them anywhere in my app. My problem is that I don't know where to do the refresh. Does Mailcore provide an NSNotification or similar when a request fails? This way I know that the token needs refreshed and I can refresh it and retry the request with the new token.
Update:
My current solution is simply to refresh the token every time the app becomes active. I would prefer to only refresh the token when it expires (i.e. when a request fails).
Instead of randomly guessing when a good time to update the token would be, use the 'expires_in' value to run some kind of logic about whether or not enough time has passed to warrant a refresh of the token.Or What I do is grab the token the first time and set a timestamp. Then, on the next call to do anything IMAP/SMTP related I check if the current timestamp is >= 50 minutes since the last update (tokens are only good for an hour so this seems to work well).
Hope this helps! :)
I recently switched to the Google+ Sign in OAuth2 hybrid approach.
When the request code is exchanged for the access token, the expiry time and created time is sent back along with the access token in seconds.
I need to know the sent timezone is. I need this to make comparison with my server's time and be able to deduce if access token has actually expired.
What's the timezone or how do I determine it?
The token bundle sent back does not include an actual expiration time, but it does contain the number of seconds for the expected life of the token. If a time is being attached to it, it is being attached by the local library.
That said - you can't necessarily trust this number. There are a number of reasons why the token may have been revoked or is treated as no longer valid. So while you can use it as an estimate of when you'll need to get a new one - you should also handle the case where you use a token and you get an authentication error, forcing you to refresh the token and try again.
My bad.
I just went through the Google PHP APi client library. Only to realize the created field was set within the library (on my server) in Google_Auth_OAuth2's authenticate method.
So it is safe to use $client->isAccessTokenExpired() instead to try to do one's computation. Works with local time (I guess :))
Thank you.
I'm calling into a 3rd party API from my ASP.NET MVC app. This API uses a service/API token that you get by calling a "renew" API. It expires after 5 days.
If you call one of the service's APIs and the token as expired, you get an "api token expired" error and you can call the renew function.
I don't want to do this because it complicates my code by having to always check for the "api token expired" error and have the logic to retry. I'd rather just make sure the renew function gets called "relatively frequently but not on every request".
I do not want to use a timer or chron solution if I can avoid it.
I thought I read somewhere that IIS7+ automatically by default recycles the application instances on a regular basis. If this default is less than 5 days then I can just use Application_Start.
You can just use Application_Start and check that it has been at least x time since the last time you renewed the token, perhaps by storing a DateTime of when the last token was retrieved in a database or file.
You shouldn't have the app automatically starting up just for this.
(my advice would be to use the API in the way it is supposed to be used; you might run into a problem with the API provider if you request it too often, for example.)