Do we have the api for creating a jwt token ?

Unfortunately, there is no API to generate a JWT token. The only way to generate or revoke a JWT token is via the RingCentral developers portal.

RingCentral API documentation is the worst documentation by a major company that I have ever encountered. So many circular references and ambiguous language, it is so frustrating to try to figure out how this shit works! Can't RC hire a competent documentation writer?

For example, this is a direct quote from a documentation page: "The key to groking how RingCentral uses JWTs is in understanding that JWTs are not used directly to call the API."

WTF is "groking"?

We are trying to figure out this JWT Authentication workflow, which, to restate my frustration, makes no sense. Documentation states that the JWT has to be created by a user, but only users who have access to the Dev Console can create JWT. How, then, are we supposed to create JWT for the other users? In the Password Flow, we have to provide username and password to authenticate the user and obtain a token for that user, but in JWT there is no way to identify which user is requesting the token. I cannot find any information about how this is handled.

Does that mean that we have to give every user in our organization permission for access to the Developer Portal, then log in with every user's credential to then generate a JWT token for every user?? Then repeat this for every customer that we have???

How can RC depreciate a working system (Password flow) without providing an adequate substitute? What am I missing?

If your app serves all (or multiple) users under the same account, you should consider using 3-legged authorization flow instead of JWT flow or even password flow (when it was supported). This will take away the hassle of asking every user to generate a JWT token or providing you with their username and password (once and every time the user change the password).

JWT token authentication should be used mainly for server-only app, which normally authenticated by a single user under an account (more often a super admin user) to operate on behalf of the company, or on behalf of other user extensions if the such operations are allowed.

There is a way that a super admin can generate a JWT token for other user extensions under the same account. But that also requires the user to login the developer portal once, so that is not really helpful in this case.

The team is still working on this area and try their best to improve documentation and JWT authentication process.

If you have further questions related to this topic, please post a new thread and focus on the technical aspects.

This response was a year ago now. Has there been any movement internally?

I have a similar use case where my users can call out, text, etc. from within our app, but the server is also taking actions on their behalf behind the scenes (subscribe to SMS per extension, send SMS using user’s number, reading sms history, etc.). So we have opted to use User JWTs but as expected the setup is very much non-ideal. Best case scenario we want to black box RingCentral from our users (as they will only use the RingCentral numbers from within our application).

What is the best path forward for us?

It’s still the same situation and I think we will not provide API to generate user JWT tokens.

The solution for your case is to implement 3-legged authorization flow, to allow each user to login once and your server will maintain the tokens until the user deliberately logouts.

Once a user logged in, you will get the token object which includes an access token and a refresh token. The access token is valid normally for 1 hour and the refresh token is valid for 7 days. You will use the access token to call RingCentral APIs and if the access token expires, you will use the refresh token to get a new access token. Remember that every time you refresh a token, you will get a new access token and a new refresh token too. Both new tokens will have new expiration time!

To maintain the user tokens, you need to implement a cronjob or similar method to refresh the token periodically (before the refresh token expires).