18

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?
Community
  • 1
  • 1
keyser_sozay
  • 267
  • 1
  • 2
  • 9

1 Answers1

26

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.

Matt Healy
  • 18,033
  • 4
  • 56
  • 56
  • @mattewh Could you help me with http://stackoverflow.com/questions/24894789/google-oauth-and-owin-how-to-renew-the-access-token-using-the-refresh-token – Marco Alves Jul 22 '14 at 18:19
  • 3
    If you have to have user interaction that's not automated. – Keith Tyler Jun 21 '16 at 20:15
  • @KeithTyler OAuth depends on user's consent at least once, after that no further interaction required. – Mohyaddin Alaoddin Jul 25 '16 at 07:50
  • The things is, the refresh token also expires, so one day the user will have to interact again. – Pierre de LESPINAY Nov 17 '16 at 12:52
  • @PierredeLESPINAY I don't believe that's the case - the whole point of refresh tokens is that they don't expire. Google has some limits around the number of refresh tokens that can be granted, but existing refresh tokens should not expire. – Matt Healy Nov 17 '16 at 12:57
  • It actually depends on the authentication provider's configuration, but all tokens are originally meant to expire. While the [RFC refresh token section](https://tools.ietf.org/html/rfc6749#section-1.5) doesn't seem to mention any expiration time, it [seems suggested](http://stackoverflow.com/questions/15564486/why-do-refresh-tokens-expire-after-14-days) to be set arround 14 days. – Pierre de LESPINAY Nov 17 '16 at 13:37