Hello, I'd like to start by apologizing if this is duplicate - I looked through several other related questions that did not exactly answer what I'm looking for.
My app uses JWT Auth Flow to login and make calls using RingOut, and I have "Issue refresh tokens?" set to "Yes" in my app settings. In my implementation, I start-up a long-running daemon thread, and on initialization I login to my platform using the JWT token I created for my client ID. I saw post requests and calls being issued as expected when first starting the thread. I expected that my initial login would never expire, and I would continue to be able to make these post requests for as long as I like without re-authenticating.
Recently, I saw a "Refresh token has expired" error when the thread attempted to make a post request. Is this expected? I thought with "Issue refresh tokens" enabled, I could extend a session without needing a refresh token. Another note on my end - I logged in with the same credentials (client ID/secret, server URL, and JWT auth token) from a separate instance. Could this have caused this error?
I am curious if this error is expected, and if so, how can I alter my implementation such that no refresh token is required? Thank you very much in advance for any help.
I don't know the logic you implement in your app to handle tokens so I cannot say much about the root cause.
But you can rely on the value of the "refresh_token_expires_in" to decide if you can use the refresh token or not. And remember that every time you refresh the access token using the refresh token, you will get a new refresh token and new expiration time too.
For the case that you login the same app with the same JWT from a separate instance, you can login max 5 instances. This means that for each user of your app, you can have max 5 tokens concurrently. If the same user login the 6th time, the first token will be revoked.
The reason I expected this behavior is based on this page https://developers.ringcentral.com/guide/authentication/jwt-flow which says that "Credentials do not expire (unless you elect otherwise)". It seems I may have misinterpreted this though?
I think the author misused the terms "Credentials". It should be called just the JWT.
So it meant that the JWT does not expire unless the owner revokes it. But when you use a JWT to get an access token and a refresh token, the access and refresh tokens will expire.
Even you don't have more than 5 instances concurrently. Every time you authenticate the app with the same app credentials and the same JWT, the system will send you the tokens (access and refresh) and keep track of the tokens. So e.g. you authenticate the main app and keep it running. Then you login the other app (which use the same app client id/secret) with the same JWT, more than 4 times, then the tokens of the main app will be revoked by the system.
Please double check your code/environment. Many developers reported this problem and all turned out that they have mistake in their code.
I think my main point of confusion is how long the access token lasts. I assumed that it would last forever, but it seems that it needs continuous refresh tokens. How long after receiving an access token until it expires?
As I wrote aboce, you have to check and rely on the expires_in and refresh_token_expires_in values to decide if the token has expired or not.
Check the documentation
Thank you for the response. I did not have more than 5 instances (only 2) so that does not appear to be the root cause.
I am still confused on JWT Auth Flow though. Is there a way such that when I login using my JWT token, I never have to re-authenticate and the session will run forever? That was the behavior I was expecting
A new Community is coming to RingCentral!
Posts are currently read-only as we transition into our new platform.We thank you for your patience
during this downtime.
Try Workflow Builder
Did you know you can easily automate tasks like responding to SMS, team messages, and more? Plus it's included with RingCentral Video and RingEX plans!Try RingCentral Workflow Builder
