Access token experation testing
See original GitHub issueI am in the process of upgrading my current application. While upgrading i have also been optimizing the code a little. I noticed something that made me question my design. Since my application is loosely based upon the Client library I thought i would check and see how we are doing it here. Turns out client library is doing the same. My Question is should it?
Observation:
As you probably know the Google Auth servers are nice and return 3600 for “expires_in” which is basically one hour in seconds. We know that the access token expires after an hour this is a fact, wouldn’t be surprised if its not in the RFC for Oauth but its been a while since i have read that.
This is what I have always done in the past.
- Turn it into a date time when I get the response back.
- Test before each call to see if its expired.
- 5 minutes before expire refresh it.
This appears to be in line with what the client library is currently doing. However the client library appears to wait until there is only one minute left on the access token and then refreshes it.
Is this really the right way to go? Assuming most APIs let you run at a max speed of 10 requests a second.
((10 * 60) 60) = 36,000
So I am potentially comparing the access token expire time with the current time 36,000 times. When you add in the fact that my application will very rarely run more then an hour. My guess would be only 10% of calls will run that long. Is this a waste? Should I just be letting the access token expire then handling that error?
I am not putting this on StackOverflow because its probably primarily opinion-based as its basically design related. However being that the client library is running this check I thought maybe you guys might have an opinion as to why the client library is checking first rather then just letting it expire.
I also realize that testing a date against itself is probably very minor when it comes to code optimization; its more the principle of the thing. I don’t like to be doing work that I don’t really need to be doing.
Issue Analytics
- State:
- Created 7 years ago
- Comments:5
Top GitHub Comments
Thanks 😃
@jskeet feel free to close this