News & Announcements User Community Developer Community

Welcome to the RingCentral Community

Please note the community is currently under maintenance and is read-only.

Make sure to review our Terms of Use and Community Guidelines.
  Please note the community is currently under maintenance and is read-only.
Home » Developers
N/A Authorization Flows using Server-only (No UI) and Public Application Type
Tags: authentication
Jan 4, 2017 at 1:55pm   •   5 replies  •  0 likes

I'm loving the developer experience so far for the most part but am trying to deal with this one weird quirk. Selecting 'Public' as Application Type and 'Server-only (No UI)' is giving me N/A under Authorization Flows. Does this mean that public server-only applications are not supported or is this a bug of some type? Thanks!

5 Answers
answered on Jan 4, 2017 at 3:19pm  
Thanks for the clarification, Benjamin. I'll get back to work :-)

answered on Jan 4, 2017 at 3:16pm  
Ah, that helps make a little more sense of things.

There are a few ways to tackle that situation:

1. Do as you've stated, and have that customer use their RingCentral Account to Authenticate to the Developer Portal. Then have them create a new Application (provide them with all the necessary settings, permissions, etc... your code will require), once they've created the application ask them to provide you with the API keys and credentials.

2. You can author your application code to operate on Heroku and implement one-button deployments. Then in your app.json you set the parameters which the customer must supply (API Keys, Username, Password) and will be made available to your application via Environment Variables. You can do this with many of the PaaS providers, and DockerHub too (IIRC).

3. Provide the source code to your customer and have them implement and deploy and provide them with placeholders where they must enter their API Key and Credentials.

4. Build the application to support a POST configuration route which expects a known X-Auth-Signature Header value, and provide the customer with the stub code to create the app and enter the required data themselves in the POST request using the one-time use X-Auth-Signature Header value you provide them.

5. Same as #4, except you provide an easy-to-use UI for the customer to enter the required configuration data which is password protected.

6. (Not exactly the same use case, but an alternative) Implement 3-Legged OAuth on a Public Server/Web application, and then provide a UI for them to configure the application.

answered on Jan 4, 2017 at 2:54pm  
I think i just screwed up by using my own developer account for testing. I've basically got a daemon running and it was fine on sandbox while I was testing. Graduated to production under that scenario because I suppose I didn't think it through. I went to set up the daemon on the end customer's' server and then ran into the authorization issue since my developer account is not associated with the customer's organization. The quick fix I attempted was to create a new app with a public type. Didn't look too closely at the allowed Authorization Flows until trying to authenticate afterward as I was trying to get it running to start working on graduation requirements. I'm guessing I should have created the app using the customers' credentials instead as it does not appear that I can change the organization under my credentials as it stands now. I'm looking at an extensive rewrite if I need to implement oAuth for this one customer, so I'm guessing I should just use their admin account to create the app? I did have to backtrack a little bit to figure out what had gone wrong since it allowed me to create the app with no authorization flows.

answered on Jan 4, 2017 at 2:16pm  
You're correct Rusty, currently Authorization Flow is not supported when application type is Server-only (No UI).

Server-only (No UI) applications are services/workers and as no client-side code is exposed, it is expected that developers can store credentials in a secure location of their choosing in the server-side (I typically use environment variables) for the running instance of the application.

Is there a use case where a Server-only (No UI) application/integration would need to be anything other than private (only able to operate with the RingCentral Account which created the application)?

answered on Jan 4, 2017 at 2:06pm  
The question is how you are going to obtain end user's credentials in this case. Public apps are allowed to work on behalf of different RingCentral accounts' users. So you will need to authenticate users somehow. If your app is headless, the usual scenario for private apps is to place credentials in configuration. But you can't do it for public app. Am I missing something?


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

Developer Platform
Integrated Apps
App Gallery
Developer support
Games and rewards

Resource center
Product Releases
App Download
RingCentral App login
Admin Portal Login
Contact Sales
© 1999-2024 RingCentral, Inc. All rights reserved. Legal Privacy Notice Site Map Contact Us