Question

Ok, so this question has been asked before here. In the response/answer to the question, the user tells him to store the refresh_token in the application (session and not db, although it doesn’t matter where you store it). After going through the documentation on Google, it seems that the access_token has an expiration date after which it is no longer valid. Now, we could obviously automatically refresh the token every fixed interval or if the service returns an invalid token error, thereby prolonging the lifespan of the token, but for some reason, this manual process feels a bit hacky. My questions is:

• Is this most effective (/generally accepted) way to access google calendar/app data for a known user account by manually logging in and persisting the token in the application? Or is there another mechanism that allows us to programmatically login to this user account and go through the OAuth steps?

Answer 1

In my application, the flow is like this:

1. If no access_token defined, redirect the user to the Google page where they grant access to your application accessing their Google data. This returns an authorization code to your app.
2. Use the authorization code to get an access_token and refresh_token. You should also save the expires_in value returned, which tells you when the access_token expires and can no longer be used.
3. Whenever you need to access the API, you can check in your DB if the access_token is expired – if so, use the refresh_token to get a new access_token before accessing the API.

I haven’t run in to any problems doing it this way – as far as the user is concerned, they only need to grant access once, then the app takes care of the authentication from there on.

That should solve your problem, because the app programmatically keeps re-authenticating itself based on the user initially granting access to your app, and you don’t need to do anything manually. In fact, I’m not sure there’s any other way to do it, because to do the OAuth process again, the user has to be sitting in front of the device to manually grant access. That’s the point of persisting the access_token and refresh_token in your database.