Cloud Elements’ Standardized Authentication How-To

We consistently hear that user authentication and instance provisioning create problems for developers. Especially for productized integrations. 

So, not surprisingly the reaction to our recently-released Standardized Auth feature — in a nutshell, an OAuth2.0 facade for any other auth mechanism — has been overwhelmingly positive. It means far less research into your target APIs and removes all the IF/THEN/ELSE logic in your code. The goal of this post is to get deeper into the how of our Standardized Auth.

Why Did We Pick Auth as a Problem to Solve?

If you’re trying to connect to an API to prototype an integration, and especially if the native API is fairly new, you’d be forgiven for asking if this is even a problem. But the moment you aim to productize a self-serve integration experience for your end-users so they can integrate your application with a handful of others (say, connecting to several common ERPs), this issue jumps to the fore. 

And the core challenge? Dozens of lines of IF/THEN/ELSE statements in your code, all dictated by the different auth types (and even varying implementations of standards—like OAuth) required by the endpoints you’re working with. 

So, what is Standardized Auth? An OAuth 2.0 facade for any API plus a credential UI that you can custom brand and then trigger with a single API call. Early adopters estimate Standardized Auth will eventually help them cut development time by 30%.

How Can You Take Advantage of Standardized Auth?

First, auth has been a challenge for years and standards like OAuth already exist.. what makes our approach any different? 

Our standardized authentication service leverages Cloud Elements' normalized APIs for each Element in our catalog and together give you:

• A single API to initiate the authentication process for any target Element
• A generated UI to present to your end-users in an iframe, pop-up, or new tab
• Automatic provisioning of a Cloud Elements instance
• Webhook notification of the resulting Element instance creation

In practice, let’s say you’re integrating a CRM, a finance platform, and a document signing service so that customers get invoiced automatically. Typically, you would need to authenticate with each endpoint using its own individual authentication method, meaning lots of development work, as well as continued maintenance in case of any changes or updates on the endpoint's side.

But by standardizing the authentication process for every supported Element in our catalog, you can quickly and easily give your users a normalized authentication experience.

Ready to Dive In? Four Easy Steps

We’ve put together a handy overview here, which covers the steps below in more detail. To summarize, you simply need to:

• Create an authentication application in Cloud Elements’ platform. 
• Add Elements to the application for the target applications.
• Create a session for the app.
• Customize the login UI branding.

1. Create an authentication application in Cloud Elements.
   • You’ll need your user and org tokens from the UI and then will make a POST/ call to the correct platform URL with a name you choose and the callback URL where you want notifications to go each time one of your users is authenticated. You then get back an application ID, which you’ll use in step two.
2. Add Elements to the application.
   • With the application ID (step 1) and the key(s) for the Element(s) you plan to let users integrate to plus required config parameters, another POST/ call (or calls) adds your target Elements to your authentication app.
3. Create a session for the app.
   • Then, when your user (or you, in testing) wants to authenticate to one of the target applications that match the added Elements in step 2, another call gives you a redirect URL and an expiration date/time (for security) so that your end-user can securely enter their login credentials for the target application.
4. Customize branding.
   • Cloud Elements automatically generates a login UI for any non-OAuth2.0 endpoints, including required authentication fields, for your end-users. You can customize the login UI's appearance to visually match your brand identity's typography, color scheme, logos, and even relevant links (e.g. links to privacy statements, documentation, etc).
   • Note that new styles and branding configurations only apply after creating a new session (step 3). The UI branding defaults to the configuration you’ve set in the UI; you can request the current arrays and then post them to the authentication application.

Voila! Authentication solved. For more and to get started, contact your account manager or view the Postman collection and a sample application on Cloud Elements Open Labs.

Want to see it in action?