Google-api-nodejs-client: Storing access tokens & refresh tokens

[suparnavg]

In the "Manually Refreshing Access Token" section of the Authorizing and Authenticating section of the the docs, it says "your access_token is now refreshed and stored in oauth2Client... store these new tokens in a safe place (e.g. database)"

As per the identity management documentation on the developers reference here, it is recommended that both the access and refresh tokens should be stored in "secure, long-lived location that is accessible between different invocations of your application."

Are there any best practices around storing refresh/access tokens in a database? If so, could this please be added to the official docs? I see a fair bit of confusion on stackoverflow as well for e.g. questions like is the id_token supposed to be used to map a user to their access/refresh tokens in the database?

Thank you in advance!

[cameronk]

I'd like to bump this. I've been searching around online and can't seem to find any good descriptions of best-practices. Most implementations look pretty complex.

[grant]

This is a good question that I think is generally applicable beyond Google APIs.

Storing authentication secrets is difficult, and how you do it best depends on context, usage, and design requirements. As such, the recommendations depends on your system.

---

Ideally, I think our Google Developer docs should store any recommendations in this page:
https://developers.google.com/identity/protocols/OAuth2

Currently, we say:

The application should store the refresh token for future use and use the access token to access a Google API. Once the access token expires, the application uses the refresh token to obtain a new one.

---

I've found a good guide on storing credential here:
https://api.slack.com/docs/oauth-safety

It references the 7-Layer OSI model, which I think provides a good guide to protecting threat from a malicious user physically accessing hard drives to intercepting network requests.

[fhinkel]

Greetings, we're closing this due to inactivity. Please let us know if the issue needs to be reopened.