Even if you have never heard of OAuth, you most likely have interacted with OAuth in some way. If you’ve ever logged into a platform via Google or Facebook, you’ve used OAuth!
Let’s say you are signing into a game on your phone via Google - meaning you gave the game access to your Google profile without actually giving the game your password to your Google account. This helps protect your Google account if the game were to ever suffer a hack or a breach. It means your Google account remains safe.
So what is OAuth really?
To start, OAuth is an open standard for handling authorization, and anyone building products can implement an OAuth authorization flow. It allows for web-apps to approve authorization without having to share password data by utilize authorization tokens to validate an identity between an individual and the service provider.
If you want to dig even deeper, the idea behind OAuth is making sure that the product or web-app you are building is able to offer secure access. The protocol works over HTTPS and helps authorize an API, device, server, or application using the aforementioned access tokens, instead of credentials like a user name and password. OAuth uses tokens (and secrets) to authorize users instead of usernames and passwords. A secret is used to verify a request is a legitimate and made by the original client application that was given authorization. You will get to see how tokens and secrets are used in action a little later in our extended example.
There are also two versions of OAuth - there is OAuth 1.0 and OAuth 2.0. The protocols are significantly different, so be wary of that.
If you are wondering which is more popular, that would be OAuth 2.0 which is the protocol we will mainly be talking about in the rest of this piece.
So just to make sure we have a good understanding here, let’s make sure we define everything involved in OAuth:
User: The individual or entity that wants to authorize one web app, API, or device to access another one of their web apps, APIs, or devices.
Client: The client is the system that wants to access to the Service provider.
Service provider: A provider that protects the account or resources of the user and receives that requests for access by the Client. It is the gatekeeper and accepts or declines Access Tokens provided by the Client.
Why use OAuth?
Prior to the rise of OAuth, applications would often ask for the user to enter their credentials directly into a webpage and the application would login as the user itself. This would lead to issues surrounding security when letting other applications access your credentials.
This lead to a need for a better way to handle authorizing into applications without actually having to provide a password. That is what OAuth is meant to do - protect your credentials and avoid the need for the user to provide another software with their login.
Extended Example of OAuth
Now that you have a little background on OAuth, let’s walk through a bit of an extended example on how OAuth works with a user, a client, and a service provider.
For this example, Tony is going to be the user, Salesforce is going to be the client, and HubSpot will be the service provider.
User indicates objective
Tony (the user): “I want to give Salesforce authorization to push contacts and opportunities I have here into HubSpot.”
Salesforce (the client): “Sure thing Tony. Let’s go see if HubSpot is cool with that.”
Client looks for consent
Salesforce: “I have a Salesforce user who wants to be able to give you contacts and opportunities that I have. Can I get a token to allow that?”
HubSpot (the service provider): “Heck yeah! You can have this token and this secret.”
User is sent to the service provider
Salesforce: “Hey Tony! We’re going to redirect you to HubSpot to let you verify that you want to give us access. Make sure to take this token with you!”
Tony: “Let’s go!”
Salesforce would then open a new tab and/or window that will show HubSpot saying “Do you want to authorize Salesforce’s access to HubSpot?”
User grants access
Tony: “Hi HubSpot! Let’s go ahead and authorize this token that Salesforce provided me with.”
HubSpot: “Hi Tony - sounds great. Let’s just confirm here, the things listed here is what you are giving Salesforce authorization to access?”
Tony: “Exactly.”
HubSpot: “Perfect, we are happy to do this! Feel free to go back to Salesforce and let them know they should be all set to use this request token.”
At this point, HubSpot has noted down that the _request_token is valid, and when used with the secret, should be valid.
Client gets the Access Token
Salesforce: “HubSpot, I want to give you this request token so I can get an access token.”
HubSpot: “Sure, the token has cleared so here is your access token and secret.”
Client has access to the service provider
Salesforce: “Hi HubSpot! I want to send some contacts and opportunities your way. Here’s my token and secret.
HubSpot: “Received! Thanks Salesforce.”
And that is the end! Tony was able to allow HubSpot and Salesforce to connect without ever having to put his on login credentials for either source at risk.
Another benefit of OAuth is that you can also go and remove the permissions that you authorized so that the client can no longer access the service provider.
Wrap-up
This was a very quick overview of how OAuth works on a macro-level. As you now know, OAuth was created to ensure the safety and privacy of users across the internet allowing multiple softwares to communicate with each other in harmony.
As the need for interoperability continues to grow with so many SaaS applications integrating with others, OAuth continues to offer companies a safe way to integrate with others.
Thank you so much for reading and check out hotglue if you are interested in offering integrations for your SaaS application today.
