How to store OAuth 2 access tokens in a database?

Question

I have seen a lot of threads on this but nothing concrete on how to do so.

I am currently getting a user to authenticate with a 3rd party via OAuth2 and I am getting an access token in return.

I would like to store this access token for a long time and so I am using a database to do so.

My question regards what to do with this database entry to ensure security.

I cannot hash it (as I would a password) as I need to be able to read and use the original to call the 3rd party on behalf of the user.

So, I am left with leaving it as is, finding a 2-way encryption method (is there a best/recommended npm package?) or another solution that I am unaware of.

I am not experienced with security regarding access tokens - so do not know the best route to take, and would appreciate any insight provided.

Thanks

Answer 1

I would like to store this access token for a long time and so I am using a database to do so

A solution for this is to encrypt the data before is saved into the database and decrypt it each time you need to access it. In your case I think that symmetric encryption is the correct choice, thus you will need to have a private key that must be kept safe at all times. The most used algorithm for this type of encryption is the Advanced Encryption Standard also known by AES and for your use case an AES-256 implementation is recommended.

While this question on Security Stack Exchange does not address exactly your scenario, the answers to it may help you to better understand the flow to encrypt/decrypt the data in a database field. This answer that contains a visual representation of the flow may be the one that you want to look first.

Now that you have a visual idea of the flow you may want to read this article that walks you through a basic encryption strategy for storing sensitive data in a database:

To safely store your data in a database, you’d start by generating a strong secret key value in a byte array. This is best generated programmatically. This single key can be used to encrypt all of the data you’d like to store.

When you perform an encryption operation you initialize your Encryptor with this key, then generate a new, unique Initialization Vector for each record you’re going to encrypt.

When your application needs to work with the data, the IV is included in the data row which can be used in conjunction with the private key to decrypt the data for use in the software.

By this time you must have a better picture in how to secure your token in the database and if am allowed to, I would like to make one recommendation and one alert before I go...

First I strongly recommend that you only support communications over a secure communication channel, aka https. No excuse nowadays to not use https, SSL certificates are now free with Lets-encrypt.

I cannot hash it (as I would a password) as I need to be able to read and use the original to call the 3rd party on behalf of the user.

Based on this I will assume that your node server is the only one calling the third part services data in behalf of the user and then exposing itself as an API to the clients using it, maybe websites and/or mobile apps.

This being true I would like to alert you that your server may become subject of API abuse as exposed on this series of articles:

• Data Scraping - Automated harvesting of proprietary data from the API.
• Account Hijack - Reuse of stolen credentials to log into accounts on your service.
• Fake Account Factories - Automated API manipulation to create large numbers of bot controlled accounts.
• Aggregation - Your data is aggregated with that of others as part of a commercial enterprise without permission.
• Cheating as as Service - Web apps that allow users to cheat gamified and rewards based platforms.