Integrations. According to a recent study by Gartner, through 2020 SaaS companies will be spending 50% of development time on integrations.
Platforms all over the world are implementing integration-first strategies to grow and scale their product usage. However, before you can offer any in-app integrations to your users, there is a crucial piece of technology implementation you need to know – OAuth.
While there are several solutions that offer integrations, these mostly handle internal automation and not necessarily user facing (read: native) integrations. This is where OAuth comes in. To know more about the difference between a workflow automation tool and an oauth solution, read our post on Pathfix Vs. Zapier.
TL;DR - Building an OAuth module requires several hours of engineering time from setting up of servers, finding SDKs that work, building token management systems and setting up the right flows. Pathfix saves hours of OAuth engineering productivity with its middleware API for OAuth integrations.
What is OAuth?
In simple terms – OAuth allows you to receive authorization from your users to get access to their data. This data does not only mean user identity, but access to data they have with their providers. OAuth framework is the most secure and preferred method adopted by most providers globally to allow for communication between applications. This is largely a two-way communication, pushing data to platforms and/or pulling data into your platform.
OAuth Scopes
Scopes limits the SaaS application’s access to the user’s data. During authorization, the user is presented with a consent screen that shows the scopes it wants to access. The user can then allow or deny access to the scope presented. The SaaS app can request access to one or more scopes which will show up in this consent screen. Scopes are always defined by the service provider; they define what data can be accessible by 3rd party and what cannot. While accessing, it is always a good idea to check the scopes permitted by the provider and enter that information that is requested as-is.
OAuth Grant Flow
The most common grant type is the Grant Flow. This flow exchanges an authorization code for an access token. Here is how a typical Grant Flow works:
Token Management System
As shown in the flow above, tokens are required during the process of receiving consent and permission from the user to access data.
These are:
- Access tokens – Applications use access tokens to gain and make API requests on behalf of the user. This token grants the requesting application access to specific data granted by the user.
- Refresh tokens – Used when an access token is expired, a refresh token is sent by the client to refresh expired access tokens. Your token management system needs to verify tokens, refresh expired access tokens, store tokens in secure and confidential data storage that is accessed by the provider only and most importantly, be secure in-transit and at-rest.
OAuth Authorization Server
The OAuth Authorization Server (AOS) is a gatekeeper that providers authentication and issues tokens. Also, it validates or rejects tokens before calls are redirected to the internal API server
The final piece, SDK’s
SDK stands for Software Development Kit (or devkit) is essentially a collection of tools you need to build on a platform. They are designed to perform specific tasks, programming, or languages. This means if you are looking to build an integration to Google Sheets to pull all new entries into your application, you will need to look for and/or build an SDK that performs that exact task complete with the programming language, API and endpoints. Most often, during the OAuth programming stage, this step consumes the most time as this requires research and finding the right and stable devkit to complete the actions you are looking for.
Or, Get Serverless OAuth Instead
So yes, building an OAuth module with the right server, SDK, token management and flows is time consuming and a bit complicated. Most service providers have their own structures and flows that you need to build for. Which means, one size does not fit all. If you are looking to integrate with multiple providers, you will need to go through this entire process again.
With Pathfix, instead of all that manual work, you can get oauth connected and start using any providers APIs in just a matter of minutes.
Pathfix is a middle API for oauth integrations that gets you connected to any provider with just a few lines of code. It handles the entire framework, token management and servers, without needing SDKs ever, all ready to go.
Reference Links
We recommend going through some of these reference links if you are looking to build the entire OAuth structure yourself https://oauth.net/2/
https://www.oauth.com/
Top comments (3)
Cool service! Unfortunately I still would need to rely on PassportJS to support a broader list of providers (e.g. Protocols.io and ORCID), but once you support more services I'd love to try! Is there any way to extend your providers like with Passport?
Our list is expanding everyday. If you could list down some of the ones that are priority for you we could go ahead and set them up. I've send you a note as soon as protocols.io and ORCID are on there :).
Internally the configuration is JSON based. For completeness, there are 4 connection configurations that are configured and released. i.e authorization, access_token, refresh_token, revoke_token and active_token and sometimes additionally request_token(when OAuth 1.0).
We did consider but it conflicts with the primary goal of simplicity of OAuth.
If you want to try it out ORCHID(sandbox) and protocols.io OAuth Configurations have been released :)