written by
Pathfix HQ

Design of an OAUTH token management proxy

Our Story 3 min read

Introduction to OAUTH2

Oauth1 and 2 are frameworks for access delegation. It allows two apps to interface with each other on behalf of the end user. The end user will have an account in both apps.

OAUTH specification is not a protocol but a framework. OAUTH 1.0 followed a 3-legged framework and OAUTH 2.0 specifies a 2 legged one. The framework simplifies the level of access (scope) the requesting app has to the user data in the service provider's app. All of it is managed by a sequence of tokens being exchanged between the two applications that finally authorizes the messages.

I need more than a few integrations

Ability to integrate into the end users work environment is synonymous to integrating into the tools or softwares they use. It’s no fun building a new notification system when you already have so many office-based communication software, i.e Slack, MS Teams etc. you could send your notifications to.

OAUTH to the rescue....

Beyond Notifications

What else can OAUTH Integrations be used for? A few use cases…

  • Read from End Users Cloud Drive (Like pictures, documents)
  • Push Data to CRM systems
  • Push and Pull Data to and from Marketing and Marketing Analytics Softwares
  • Integrate Devops with Ticketing Systems
  • Pull data from multiple systems to and provide ML based reporting
  • Read mail subscribers from popular bulk mail providers
  • Fetch videos from popular video service providers
  • Push messages into Social Media
  • Many more… The list is endless with so many special purpose softwares being built, Integration strategies will sit deep rooted into product development life cycle.

The problem was big enough, with no simple solution!

The Ideation Stage

Our Goal was to keep it simple. We wanted to make sure we stuck to our goal and designed a system that followed the same approach: Keeping it simple.

We listed out our set of questions that would led to designing the system the way it is.

Some of these were…

  • Should we create API and distribute SDK’s?
  • How many will we create?
  • What languages will we support?
  • Will we redefine our SDK to override those of the service providers?
  • Will we create API SDK’s for smaller service providers (who support OAUTH)?
  • How many versions of SDK’s will we maintain?
  • Will developers have to familiarize themselves with our API?
  • If we do create the libraries, should we not distribute the libraries as opensource?
  • Well, that would be one more batch of libraries, wouldn’t it?

The Aha Moment

“Can we create a pass through that only solves the access token management and refresh? We should not have new API, only an interrupt that does not aim to overachieve.”

Pathfix Was Officially Born

And here is what we came up with: An authorization solution that enables integrations without needing to download or install SDK's - A passthrough solution.

Here is what it would do:

Authorization

  • Provide developers with a Redirect URL that they register with their Provider.
  • Ask the developer to register the ClientId and Secrets in our encrypted key vault.
  • When the user authorizes with the service provider they are redirected to Pathfix server.
  • Pathfix exchanges this information for a token and refresh token and holds it in a token vault with a some additional information. 1) Provider ( Slack, Ms Teams) 2) Your User’s Id and 3) Your Pathfix Id.

Integration

  • Pass all the messages with the exact payload as defined by the service provider to our servers
  • When doing this pass the same parameters: 1) Provider ( Slack, Ms Teams) 2) Your User’s Id and 3) Your Pathfix Id
  • We stamp the message with the token and send it over and give you the exact response returned by the provider.

All done in simple 2 step process, all done in less than 5 minutes!

Time to put it to test

We began to use it in most of our applications internally and it worked perfectly. Our developers absolutely loved the fact that they no longer had to build out frameworks, token management systems or servers to manage oauth.

No one had to learn any new API's, or download and install SDK’s. It was a simple few lines of code with a few replacements, and we were off to the races!

42: The answer to everything

We just introduced a technology solution with libraries. A complete serverless oauth solution that was ideal for anyone who wanted to save time and effort (read: money!) while building integrations.

Check out Pathfix here. Need help? Email us!

integration #oauth2 #oauth1 oauthproxy
SaaS and OAuth integration insights delivered to your inbox.
Sign up for our newsletter