Using a serverless oauth token management system

OAUTH2 – An Intro

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 application that finally authorize messages.

The Use Case

I am an online Photo Printing Service provider – PrintPixie. Registered User can upload a photo or connect to Cloud Drive where they hold their photos, select print parameters, pay and submit their order. In this use case we have…
  • Client – PrintPixie
  • Cloud Drive Service Providers – Google, iCloud, Onedrive etc.
  • End User – Say megan@personalemail.com

The Integration Strategy

Here the integration strategy is as follows…
  • Fetch the list of photos (thumbnails) available on the end users cloud drive
  • Pull a high res image once the user has made a selection
There are two ways to implement this
  • Managed Server
  • Serverless

Managed Server – Implement code in PrintPixie

Assumption that PrintPixie is built using Python. Here is a sample top level task structure.
  1. Register printpixie with each of the service providers’ as a client app to fetch the clientId and clientSecret and provide a redirectUrl to your server (Task 3. Below)
  2. Download Python Authentication libraries/sdk’s for each of the providers.
  3. Create a server API to handle authorization redirect.
  4. Call the authentication library to get access token.
  5. Create a data store to hold end user Access Tokens.
  6. Write integration wrapper to GetListOfPhoto GetHighResLocation
  7. Fetch previously retrieved end user access token from data store and refresh if expired
  8. Map each of the above interfaces to the service provider API in their library.
  9. Make the call
  10. Attach tokens to call
  11. Log call
  12. Log errors
  13. Notify if there are any errors

Serverless- Use an OAuth proxy 

By redirecting your Authorization and Messaging through a service. Pathfix offers this. It proposes that we try a slightly different approach to all of this. Here is how they would do it.
  1. Register printpixie with each of the service providers’ as a client app to fetch the clientId and clientSecret and provide a redirectUrl (provided by Pathfix) to your server (Task 3. Below)
  2. Write integration wrapper to GetListOfPhoto GetHighResLocation
  3. Map each of the above interfaces to the service provider API in their library. (Usually using a JSON file to map API interfaces)
  4. Make the call
The entire process has reduced from the original 13 step process to a simplified 4 step process!

Summary

We see that there is a significant reduction in the time to live. Not only have the no. of tasks reduced but it has freed up a developers time to get to the specific integration much quickly. With this method if you have an Integration Strategy in mind (like PrintPixie did), you can go live in a couple days if not less.
What is Single Sign On (SSO)? How can you add it to your existing login?
See why adding a single sign on (SSO) makes user and business sense and how you can add an SSO button to your existing login module in less than 5 minutes
Top 5 productivity tools to integrate your SaaS with in 2020
A list of the top 5 productivity tools SaaS platforms should integrate with in 2020.
Is Pathfix like Zapier?
Is Pathfix like Zapier🤔? A lot of times users get us mixed up. So, to put the whole ‘Pathfix Vs. Zapier’ discussion to rest, we thought it best to write out a blog that details why we are nothing like Zapier. Read more on how Pathfix is NOT like Zapier.