Getting a new refresh token (not a login issue)

We are building a basic SMS app using the PHP RTC method. We were away from the project for two weeks and now all of the tokens are expired. I know the login credentials are correct because we use them to login to this portal. I am getting the " Refresh token has expired" error. My code that authenticates the app is below - how to I get new refresh tokens?

$this->ringcentral_clientid = 'xxx';
$this->ringcentral_clientsecret = 'xxx';
$this->ringcentral_server = 'https://platform.devtest.ringcentral.com';
$this->ringcentral_username = '+1xxx';
$this->ringcentral_password = 'xxx';
$this->ringcentral_extension= '101';
$this->rcsdk = new RingCentralSDKSDK($this->ringcentral_clientid, $this->ringcentral_clientsecret, $this->ringcentral_server);
$this->platform = $this->rcsdk->platform();
$this->platform->login($this->ringcentral_username, $this->ringcentral_extension, $this->ringcentral_password);

Let me see if I can help. Phong is correct, in all likelihood you are using the incorrect credentials, but I will admit, knowing which credentials to use can be confusing. So let's break it down.

When you go to developers.ringcentral.com and create an account, you create a "developer account." These credentials are used for logging into the developer console, the tool used to create apps, get client IDs and secrets, and so forth.

When you created your first app, you were prompted to create a "sandbox account." A sandbox account is used to access our sandbox environment, a replica of our production environment (with some limits put in place to prevent abuse). The developer sandbox provides you will a complete test environment in which to build your app. You have access to SMS, telephony, team messaging, and so forth.

Your sandbox account credentials (NOT your developer account credentials) must be used for authenticating to the API in our sandbox environment (platform.devtest.ringcentral.com). Your credentials will be a combination of 3 things:

* Your sandbox account's company phone number
* Your sandbox account's extension
* Your sandbox account password - which you specified when you created your sandbox account when you created your first app

You can find these credentials by logging into the Developer Console and clicking the "Sandbox Accounts" menu item. There you will see the "Main company number." This is your username. Your extension is almost certainly "101" and your password... well if you have forgotten your password, click the "Forgot password" link from the Sandbox Accounts page and follow the on-screen instructions.

-------

Next, let's talk about refresh tokens. When you first connect to the API (in production or sandbox) you will get an auth token that is presented subsequently via the HTTP Authorization header, and a refresh token. The auth token expires, and when it does you present the refresh token to the API to get a new one. Refresh tokens also expire (although they live longer than an auth token). When both an auth token and refresh token have expired, you need to present your username/extension/password credentials to the platform again in order to restore connectivity.

I am hoping the information above helps you resolve the problem you are having. If not, remain patient. We are committed to helping you be successful.

Byrne Reese
Product Manager, RingCentral

We may want to escalate this case to our developer support team so that we can exchange more information - sample code, client ids, and so forth. Without seeing your code, I can only help at a high-level, but I will do my best. So, if you have two apps, both are configured identically: both are private, and thus both configured for "password-based auth," yet you still cannot authenticate... I understand from the thread that you do NOT have a problem with presenting a username and password to retrieve a temporary auth token, and you do not have a problem with exchanging your auth token for an access key. But you do have a problem with exchanging old access keys for new ones using the refresh token. So, access keys (this is the "token" used for auth) can be re-used and last about 1 hour. Refresh tokens are provisioned at the same time you get your access key, they last about 7 days, and they can only be used once. When you present your refresh token to get a new access key, you will get a new access key and a new refresh token. At this time, the old access key will be invalidated as well. With this in mind, here are some things I have seen developers have problems with: 1. There is a race condition in which a refresh token is used to get a new access key. I have seen this when developers are dealing with error conditions in which an exception triggers the retrieval of a new access key via a refresh token. This in turn triggers the invalidation of tokens which causes another error, which causes the first thread to fail. Or something like this. It is hard to predict since not every developer codes their app the same way. 2. Developers mistakingly presume that access keys are permanent, and/or refresh tokens are permanent. They store them in a database, and when they expire they start seeing auth errors. 3. Our auth system is rate limited. So if a developer is triggering a lot of errors, which causes them to retry API calls in an attempt to debug the problem, the increased traffic triggers your app to be throttled, causing another error. So let me recommend some ways to debug the problem. 1. Do not (for now) rely on refresh tokens. Have your app auth each and every time you need to make an API call. In other words, use the access key only once. If this works, then we can be sure that your credentials are correct, and your app is configured properly for username/password auth flows. 2. Next, we need to find the right strategy for access key re-use so you don't need to need to re-auth every time. The recommendations here will vary depending upon the nature of your app. If you are writing a script that is running in its own process, and is relatively short-lived, you should be able to store the key in memory just fine. If the app is a long-running server-side process, then you may want to use some kind of mutex lock on the API key when it is being refreshed to avoid a race condition. Those are my current ideas. If you would like, I would be happy to schedule time with you over the phone to help on Tuesday.