From the earliest days of software development, authentication (also called auth) has been important. To ensure system and data security, we must ensure that only correctly identified users can log in to a system.

If you're building native integrations to connect your SaaS product to the other apps your customers use, one of the tricky pieces is dealing with the nuances of third-party apps, including authentication. Sometimes, you'll be the one setting up authentication for your app, and sometimes, you'll need to configure your integrations to use whatever auth pattern is already defined. In either case, knowing how user authentication methods work and what to look for can save time and prevent integration headaches.

How have authentication methods changed?

We have helped our customers enable native integrations using basic authentication, API keys, and Open Authorization 2.0 (aka OAuth 2.0), including numerous non-spec variations of OAuth 2.0. Auth type preferences have certainly changed, with basic authentication being the original approach. However, newer development has moved on to API keys and OAuth 2.0 for reasons we'll get into shortly.

Because basic auth has been around for a long time, many systems continue to use it, and many cannot be easily updated to use API Keys or OAuth 2.0.

Let's look at how these main authentication methods work and dig into the details within the context of native integrations. We'll also touch on authorization (permission to access specific resources), but that is not the focus of this post.

Understanding the basic authentication method

Basic authentication uses the classic username and password approach. As noted, this is no longer common in modern SaaS apps, but we still see it implemented with many legacy systems, including FTP or older HTTP-based apps.

For the simplest use case for basic auth in HTTP, take the username and the password, put a : between them, and use base64 to encode the whole. Then, place the entire base-64 encoded string as a header in your HTTP request:

To ensure it conforms to standards, always use theAuthorizationprefix for the header with theBasic {base64 encoded username:password}value.

An even simpler way is to place the username and password at the beginning of the URL:

However, this pattern has long been deprecated because typing credentials in the open, where anyone can read them, isn't a good security practice.

Why SaaS teams use the basic authentication method for integrations

The draw of basic authentication for integrations is simple: basic auth is super easy to implement. All you need to do is decode the base64-encoded header and verify that the username/password combination is correct. That's it. Because of its simplicity, basic authentication makes sense when you build custom integrations in-house without using an API or integration platform.

Teams generally use basic auth for legacy HTTP services or services that don't support other auth options. Database connections using PostgreSQL, MySQL, and MSSQL (among others) also rely on basic auth.

It's important to remember that basic auth doesn't mean a lack of security. For example, with Prismatic, basic auth (and HTTP headers) are encrypted in transit with TLS 1.2 or greater.

Things to consider when using the basic authentication method for integrations

While basic auth is simple to implement, it does have a few negatives. Every integration gets the same credentials, and you cannot limit the scope of the credentials. That is, you can't change the authorization tied to the credentials. As a result, each integration can do everything permitted by the credentials.

And, if you were to change the credentials, each integration that uses them would need to be individually updated to the new credentials. This largely manual approach to setting and updating credentials means that basic authentication does not lend itself to being used for integrations at scale.

Understanding the API key authentication method

An API key is a single string used both for identification and authentication, particularly with reference to integrations that use an API (application programming interface). Auth based on API keys is often referred to as token-based auth and is common in modern SaaS apps.

To set up auth using API keys, your app creates a key for you to use with your integration. You can often generate a key in an app under a Settings or Profile menu.

An example of an API key in an HTTP request looks something like this:

You may notice that the pattern is very similar to what we used for the basic auth, having theAuthorizationheader, but this time using theBearer {token}value.

An API key may also be passed in as a parameter for some APIs:

Or, you could even use a custom header for the API key:

Why SaaS teams use the API key authentication method for integrations

Though API authentication methods require a bit more to set up than basic authentication, they are easy to implement. Usually, the generating app stores the API keys (or hashes of those keys) in a table and matches the keys up with the corresponding users.

One benefit of using API keys is that you can set the scope of the permissions (authorization), unlike with basic auth. You might set up a single token to have read-only access to specific resources while setting another token to access all resources available through the API. As a result, you can use different tokens for each integration, and it doesn't matter if a user changes a password – the API key remains mapped to that username. If an integration no longer needs access to the API, you can remove the corresponding API key from the app.

API keys are ideal for integrations with your app if you are using an embedded integration platform (also known as embedded iPaaS).

Many SaaS products offer support for both API keys and OAuth 2.0. API keys are handier for headless integrations because you can often programmatically create an API key in one app and use it in an integration in another app without direct human intervention.

Things to consider when using the API key authentication method for integrations

Users need to copy and paste API keys from one app to another. This manual step takes little time, but it can cause issues when data isn't cut and pasted correctly. Another drawback is that API keys don't usually expire. As a result, someone could compromise an API key, which would continue to function until someone goes into the source app to disable it.

Understanding the OAuth 2.0 method

OAuth 2.0 is everywhere. You've no doubt used it with numerous apps yourself. In general, it is set up so that you click a button in App A, and App A sends you over to App B to ask if you wish to enable sharing of something (email, etc.) with App A. You click the button to agree to this data sharing, and App A is granted permissions to App B on your behalf.

While this is surprisingly simple on the surface, the complexity is handled behind the scenes. Here's how it works:

Why SaaS teams use the OAuth 2.0 method for integrations

One of the most powerful characteristics of OAuth 2.0 is that authorization (permissions) can be easily scoped to the specific access needed: read access to accounts, read/write access to contacts, etc. Each integration can use a different access token, and it doesn't matter if a user changes passwords; the OAuth access token will still work.

Revoking the refresh token is also straightforward, thereby disabling a user's ability to generate a new access token. Also, if an access token is somehow compromised, it usually expires quickly and limits the damage that could result.

While OAuth 2.0 is well suited for building integrations to third-party apps using an embedded integration platform (embedded iPaaS), it's also the most powerful and secure approach to authentication – no matter what you do for integrations.

Teams like to use OAuth because it provides a clear, foolproof way for their customers to authenticate. There is no room for error. There are no transcription issues with copying/pasting API keys. Users click a button, consent to permission sharing in another app, and connect.

Things to consider when using the OAuth 2.0 method for integrations

There is more overhead to using OAuth 2.0 than using either basic auth or API keys. You'll need to build the infrastructure to track the client IDs and client secrets for any of your apps that use OAuth 2.0. In addition, your app/API will need to be set up to create a callback URL that takes the Authorization Code as input and exchanges it for the access token and refresh token (when applicable).

Finally, you'll also need to build something that will periodically refresh the access token. This could be a cron job, AWS Lambda, etc. Or, using a tool like Prismatic lets you rely on an OAuth service to handle the refresh for you.

How to choose an authentication method for your SaaS integrations

If you are building custom in-house integrations between your app and third-party apps, it probably makes the most sense to use OAuth 2.0 because of the user experience and built-in protection. If you can't take that path for whatever reason, then using API keys should still provide a good user experience and decent security. Basic auth, while it has its niche, is not optimal for most modern SaaS apps.

If, however, you use an embedded iPaaS to create, deploy, and maintain native integrations with your app, then the platform should come with built-in connectors to many applications that handle most of your authentication needs without requiring you to write additional code. You might even be able to set up your app so that an API key is created, and then that key is provided to your customer within the integration config when the customer activates the integration.

Auth is essential for integrations

Whether you build your integrations in-house or use an embedded integration platform, understanding user authentication methods will help you execute your integration plan.

We understand that setting up auth for integrations can be painful. Among other things, even though there are standard approaches to auth for APIs, many APIs don't implement the standards fully, or they have their own twist as to how things must be done.

One of the ways an embedded integration platform reduces the hassle of working with auth for integrations is that it comes with a number of pre-built API connectors (and other components) that have auth already incorporated. Provide the necessary credentials and you'll be connecting in no time. Or, if you need to build a custom API connector, you can use existing code as a pattern to solve for your unique scenario.

If you are interested in seeing how an embedded integration platform can remove much of the hassle of building auth into integrations and make it easy to use the best authentication methods for your integrations, please contact us.