Storing Access Token

  • 1
  • Question
  • Updated 4 months ago
Does RingCentral recommend anything as far as safely storing your OAuth Access Token? Is it okay to save it in plain text in my database and allow users to see it? Should it be hidden from users? Should it be encrypted?
Photo of Ben Carpenter

Ben Carpenter

  • 146 Points 100 badge 2x thumb

Posted 4 months ago

  • 1
Remember that the Access Token expires in 60 minutes. If you store it somewhere (whether hidden or not) it will become invalid unless a renewal request is submitted in less than 60 minutes from the moment it was issued.

Personally, I save the App Key and App Secret in my programs and use a Base64 encoding function I wrote to generate the "Authorization" field in the REST statement (Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxx) when requesting an Access Token.

This way, the Access Token is not stored anywhere.

HTH,
Vick
(Edited)
Photo of Tyler Long

Tyler Long, Official Rep

  • 9,828 Points 5k badge 2x thumb
Access token expires in 60 minutes by default.

User can refresh it with refresh token. Token refreshing also requires clientId and clientSecret of your RingCentral app.  So do keep your clientSecret a secret.
Photo of Ben Carpenter

Ben Carpenter

  • 146 Points 100 badge 2x thumb
Thanks, Tyler.

Does RingCentral have a recommendation for how to hang on to the clientSecret while keeping it a secret? Hardcoded in the server code? Encrypted in our Database?

Thanks Again.
Photo of Phong Vu

Phong Vu, Devangelist

  • 5,406 Points 5k badge 2x thumb
Hi Ben,

RingCentral does not have a recommendation on how developers should keep the clientSecret. You should threat it the same way you do for any other services' client id/secret, tokens etc.

I would not recommend to hardcode in your server code. You can keep it in your database or environment .env file. The secret itself is encoded so I think it is not necessary to encrypted it again.

+ Phong
Photo of Ben Carpenter

Ben Carpenter

  • 146 Points 100 badge 2x thumb
I'm not sure what you mean when you say "the secret itself is encoded so it is not necessary to encrypt it again". If someone gets the Refresh Token, the Secret that I would be storing, and the ClientID, they can then get the Access Token and make calls. Correct?

If so, don't I need to either hide or further encode at least one of those?
(Edited)
Photo of Phong Vu

Phong Vu, Devangelist

  • 5,406 Points 5k badge 2x thumb
I meant the secret is an encoded string e.g. "qwd6qHnYTuKjpWETvXrf1ghPXbLFs3QKWuNnJiHUd8IQ". If you want to encrypt and decrypt it every time you use it, you have to write your code and run the code to convert it back. Now, where is a safe place for you to store that code and algorithm to encrypt/decrypt the secret? Can hacker access that place? If it is hard to access the place you store the code, that place should be 'safe' to keep the secret too. Of course, if you encrypt/decrypt the secret and other credentials, it is just harder for hackers to steal and use the secret.
I would convert the id/app secret to binary and execute a logic operation like AND / NAND / OR / XOR  with a particular value (such as the filename truncated or elongated so that its binary value would contain the same number of bits as the id/app secret) and save that value in your program.

This would allow you to save the id/ app secret in a form that would not be useful to anyone unless they know exactly what logic operation you are executing and what values you are using to perform the logic operation.

Whenever you need to use the id/app secret, simply read the value from your program and reverse the process.

Just a thought ....