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?
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
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
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.
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.
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
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
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.
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.
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.
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?
If so, don't I need to either hide or further encode at least one of those?
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 ....
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 ....
Since the Access token has expiration time of 60 minutes , one of the easy and better way would be use Cache and storing it into Cache for 30 mins rather than storing it into a database. This will also help in efficient call of API reducing the rate limit issue. Storing in DB will not be a good idea as it will be expiring after 60 mins and so no use of storing it
4 People are following this question.
