How to Encrypt OAuth Tokens in 10 minutes With SecureDB

So, you are building (or have built) an app that allows its end-users to authenticate with an existing social login (ie. Facebook). Or maybe your application aggregates information on behalf of the users using OAuth (ie. Hootsuite). Or, perhaps your application takes actions on your user’s behalf when they are sleeping.

In all of these scenarios, APIs are at work and OAuth is invariably involved as a means of Authentication. This means that you are probably storing the end customer’s OAuth Tokens in a database. You are not alone. A vast number of websites and mobile apps that provide social login use OAuth (instead of user IDs and passwords)  to log the customers in. Service providers such as Twitter, Facebook, Google etc. readily provide OAuth (1.x and 2) Integration so that developers can easily build a social login screen.  

The OAuth Framework depends on one simple premise: You, the application owner must maintain the secrecy of the end customers’  OAuth tokens. Compromise of these tokens (which has happened in the real world), would essentially allow the attacker to authenticate on behalf of the end customer and do a lot of damage.

Some of the secrets to be protected here include:

  • OAuth Bearer Tokens
  • Any application-specific API keys and API secrets (often generated when an new application is first registered as a user of an API)
  • OAuth Access Tokens and Access Token Secrets


Encryption. While in transit and at rest. These secrets must be protected with symmetric encryption at rest. Whereas encryption in transit is often handled by Web security ( TLS), the rest of the article shows how to handle encryption at rest in 10 minutes using SecureDB’s Encrypted Identity Manager.

Two things to note: First, SecureDB can be joined with other non-SecureDB databases in a way that SecureDB is used specifically to handle the encryption and storage of secrets at rest. Second, SecureDB’s Encrypted Identity Manager is not specific to encryption of OAuth tokens. It allows developers to extend the Identity Manager to encrypt and store other sensitive data as well.

Step 1: Create a table with encrypted columns

1. Login to SecureDB Dashboard. Click on ‘Encrypted Data > Schema’. This shows a list of tables you have already created.

2. Let’s create a new table called ‘oauth’. This table would store oauth tokens for every user in your system. To do this, first click on ‘Create Table’ and enter the name ‘oauth’.

3. The table already comes with a default id column of type uuid. Let’s use this column to store end user’s unique identifier.

4. Now, let’s create two more encrypted columns that would store end user’s user_token and user_token_secret. To do so, click on ‘Add Column’. Enter ‘Column Name’ and ‘Type’ as shown below. Click ‘Update’. This creates an encrypted column called user_token’. Any data inserted into this column would automatically be encrypted using AES-256 in CBC mode.

5. Repeat the steps for user_token_secret. Now the table looks like this. As you can see, we have two encrypted columns ready to store OAuth tokens encrypted.

Step 2: Insert End User’s OAuth Tokens

Now that we have a table capable of storing encrypted data, let’s go ahead and insert sample OAuth tokens. This can be done via SecureDB RESTful APIs.

1. To access the Swagger based APIs, click on ‘Encrypted Data > API Playground’.


2. Click on the ‘Insert data into the table’ API to expand it.  Enter sample data for columns id, user_token and user_token_secret as shown below and click ‘Try it out’. Please note the table name (oauth) is same as the one we created above. Here is the sample data for you to insert:

    "id": "a6658a5d-4bb8-4d58-bfa5-fc42b55ae79f",
     "user_token" : "user_token1",   
    "user_token_secret": "user_token_secret1"

3.If you got HTTP Response Code 201, that means data has been created successfully in SecureDB and it has been encrypted using AES 256 CBC mode.  Here are few more sample snippets for you to enter into the ‘body’ section of that API:

[{    "id": "b7dd505a-1838-43c9-b21b-6dc3bc4f4530",
      "user_token" : "user_token2",   
    "user_token_secret": "user_token_secret2"
{    "id": "e93c8ba6-e4bb-4262-bf10-a9f51c155394",
      "user_token" : "user_token3",   
    "user_token_secret": "user_token_secret3"

4.That’s it. You have successfully encrypted the end user’s OAuth tokens. Do you know what the data looks like in the database? Here it is: data is encrypted!

Further Security Considerations

  1. SecureDB APIs require you to provide Basic Authentication header with every API call.
  2. SecureDB allows you to set up an ‘API firewall’ ensuring that only server’s whitelisted IP addresses  can call the SecureDB APIs. Any calls to these APIs from other servers will be rejected. 

Be sure to read the next Security article: Study Highlights Security Risks of Various Programming Languages