New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Storing access tokens & refresh tokens #853
Comments
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. |
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: Currently, we say:
I've found a good guide on storing credential here: 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. |
Greetings, we're closing this due to inactivity. Please let us know if the issue needs to be reopened. |
This post has been open for a 6 years, and I'm closing in a cleanup effort. With regards to best practices for storing a refresh token? My recommendation would be using a service like Secret Manager which stores the refresh token encrypted at rest. If you use another option for persisting, e.g,. a persistent database, research if there is an option to store the field encrypted at rest. Also be careful when using the secret, it should only be transported over SSL, never over an HTTP connection that could be monitored. |
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!
The text was updated successfully, but these errors were encountered: