Since the password auth flow isn't available in public applications
I don't think so. Where did you get this information?
what is the max that the 'refresh_token_expires_in' value can be set to?
A week, or 604800 seconds.
a private application can only send messages from the account it was built for
Private apps will be available for the users belonging to your RingCentral account only. Public apps will be available for users from other RingCentral accounts as well.
I don't think so. Where did you get this information?
I don't see it anywhere in the docs, but when creating a new app, the Authorization Flows that appear when 'Public' is selected don't include password flow, no matter the platform type. Also, I tried authenticating via password flow in a public application and received an error message letting me know that I was unable to authenticate using that method. Should I be able to use password flow in a public application? Do you know how I could enable that functionality?
Hi, I just checked and I think you are right. Public app does NOT support password flow. I was not aware of this limitation before.
So is there another way to authenticate a client or retrieve a new auth token in the background so users won't need to enter their credentials on a regular basis?
Hello Grant,
Using the Authorization Flow (3-Legged OAuth), your application code can enable customers to authorize an application to act on their behalf. Once a user has granted your application permission to do this, the Redirect URL of your application will receive a request with a "code" which your application then uses to obtain a valid "access_token" for that user (it also will have a refresh token). Here are some Authorization Flow implementation examples in multiple languages:
https://github.com/grokify/ringcentral-demos-oauth (you can also find these organized by programming language on the
RingCentral Developer Portal SDK page).
Your code should cache the access_token and refresh_token, and then set a timer based on the refresh_token_ttl (the length of time to live for the until the refresh token expires).
Your application code should use the refresh token flow, when one of the following occurs:1. Your access_token has expired, and the refresh_token is still valid
(this is typically done while the user-session is still active).
2. When 80% of the refresh_token_ttl seconds have expired (this way your application still has 20% of the TTL seconds available in cases where there is a non-HTTP-200 response received while attempting to refresh your refresh token
(this is typically done for long-running processes or service-workers such as what you've described for your use case).
The reason that RingCentral prohibits Password Flow on Public applications is because when a developer indicates an application will be public, that application has the ability to be installed in RingCentral accounts which are NOT part of your organization (which means that your API keys will be invalid for use while attempting to obtain an access_token) and because otherwise you would be required to store RingCentral usernames/passwords in your database(s) and this is a security risk we do not want you to be responsible for owning, and which we do not want to expose upon our users.
Dean is correct. You can use the refresh token flow to refresh the token on a regular basis(to obtain a new refresh token before it expires). Each user only need to authorize your app once and only once.
