What is Open Authorization? How does this framework work?

• OAuth
• Open Authorization
• OpenID
• SAML
• Sign-Up
• Social Media

Imagine what would happen if every time you had to enter a grocery store, you had to give them your social security number. Or every time you meet a new person, you had to provide them with your address and phone number as a social obligation. Thankfully, society does not dictate such practices. This set of information is private for a reason and can be trusted by only a few. Similarly, when you linger on the web, using applications and websites from across the globe, you shouldn’t have to give away passwords of your accounts. If a website demands your bank login, promising to keep it safe—abort mission immediately. This is how OAuth came into the picture. If you were playing a game on Facebook, which requires your pictures, then you don’t have to enter your Facebook credentials to access it. You could hand over this responsibility to OAuth, that will do the deed for you.

OAuth has been a confusing concept. While some reads are providing an in-depth technical insight, which isn’t for everyone. Not everyone trying to understand OAuth is a Developer, neither do all developers wanting to understand its concept want to dive into full-blown technical depth on the get-go.

This read provides a high-level explanation of the core concept of OAuth. What exactly goes on internally that helps you log in through your Gmail account itself on a variety of applications.

What is OAuth?

OAuth, short for Open Authorization, is pronounced as “Oh-Auth”. It is an authorization protocol that helps websites communicate, where one application takes permission from another to access some of your information on it without revealing any of your credentials whatsoever. It is an open-standard which uses JSON language and mainly works on API calls between servers.

OAuth started with version 1, now, primarily, OAuth 2.0 is in use which is drastically different from its predecessor. They are so different that they aren’t even compatible anymore. You can’t backtrack OAuth versions. You have to design it for either of the protocols. In this read, when we say OAuth, we are addressing OAuth 2.0.

It is essential to note that OAuth is an authorization tool, not an authentication tool. It only checks if a website has access to use your information from another. It does not authenticate your identity. To put it simply, it does not check if you are who you claim to be, it checks if this website has your consent for use.

Understand the difference between authentication and authorization.

OAuth language- Its parameters

Consider this example. You want to use Pinterest. It provides you with an option to login through Facebook.

It is asking you, “Hey, there. You want some inspiration for an image, why not save some time and login through Facebook?”. It saves you the hassle of creating another account and remembering yet another password.

When you decide that’s better, you outsource the login work to Facebook.

Now Facebook will ask you, “Hey, Pinterest just spoke to me. It wants access to some of your details. What do you say?”

Now you can look at the list of permissions that Pinterest has demanded. For example, you have to provide your name and profile picture, but you can decide if you want others to know you are using the app. Or you can decide if you want Pinterest to access your friends list on Facebook. You can uncheck anything you don’t want to provide permission to and click allow in the end.

Now Pinterest and Facebook have successfully communicated with each other for you. You can use the app without revealing your credentials.

Now, let’s address them in the OAuth parameters. The user or the resource owner, server and the client.

The resource owner is you!

The server the application to which you’re logged into with credentials: Facebook.
The client is the second application that wants your information: Pinterest.

The scope is the extent to which you want a client to access the information: Your app permission of friends list.

OAuth – Real-life example

Here is a real-life example for you to understand the concept better before we talk about the internal workings.

Let’s say your name is Harry. The server is the data on your phone. The client is Ron, who has run out of data but has an important skype meeting coming up.

Being a good Samaritan, you want to help him, but you don’t want to give them your phone, you aren’t that charitable either.

Hotspot comes to the rescue! With hotspot, you can delegate your data to Ron, without giving your phone. The scope of this in your hands too. You can decide how long you want Ron to use your hotspot.

There you go, you haven’t given away your phone and sat anxiously wondering if Ron is snooping around in your phone, and at the same time, you did a good deed.

How does OAuth work?

We have gone through the basic concept of OAuth. The story of an app, another app, and your identity—without compromising any of your passwords.

Now, let’s go a level deeper and understand what goes on to enable it. When you select to sign up through Facebook, the following ensues:

Step 1: Pinterest approaches Facebook and asks for a consumer key and a consumer secret. This helps the server, Facebook, to verify the consumer, i.e., Pinterest.

Step 2: Once Facebook says here you go, Pinterest asks for a request token. As the name suggests, this token is to request you allow or deny access to Pinterest from you, the user.

Step 3: Once Pinterest receives this request token, it redirects you to Facebook so that you can heed to this request and decide if you want to allow or deny and decide the scope.

Step 4: If you allow, then Pinterest will ask for another set of keys called access token using the request token.

Step 5: Pinterest receives the access token, now, as decided by you, Pinterest will be able to use your resources on Facebook.

Through these bunch of redirects and keys, you have now enabled Pinterest to login using your Facebook account.

Is OAuth secure?

When OAuth 2.0 released, it did get a lot of flack for not being as secure as its previous version. This is because it does not have security inherently built-in. That means no encryption of any sort, on purpose. If you want it to be secure, then the developer has to use Transport Layer Security (TLS) over it. The implementer has to sign all the requests with encryption to prevent the various forms of cyberattacks.

Sometimes a user can be phished using OAuth. You try to use an app, and it redirects you to a Facebook login page. You enter your Facebook credentials, thinking you are only logging in to provide access to the third-party app. What you don’t realize is, this page might be a dummy Facebook page, created to phish credentials off of people. You must carefully look where exactly you are entering your details. Another good practice is to always see if the webpage has a TLS layer. If you see HTTP:// instead of HTTPS:// in the URL, do not enter your credentials as these sites are not encrypted. This is a good digital practice in general.

OAuth and SAML

SAML is an XML based protocol that helps you to authenticate and then authorizes you into the designated applications. Whereas OAuth only authorizes.

Also, OAuth, owing to its API functionality, can communicate with a range of devices. Internet of Things, mobiles, and more, all of them can talk to OAuth, while SAML is more of an enterprise-level option.

This is why SAML is losing popularity over OAuth, even though it uses session cookies and is more secure. But because of questions like “why would you log in to your Echo over and over again on the same day with SAML when OAuth can keep you logged in?” is the reason why OAuth has taken over.

Related read: What is SAML?

OAuth and OpenID

These currently do two different things. OpenID authenticates users while OAuth authorizes. They complete each other and aren’t in competition, owing to the two different roles they play.

OAuth helps machines interact with each other. OpenID helps you and machines interact with each other. OpenID essentially is an authentication layer over OAuth.

Further reads:

This read aimed to introduce you into the world of OAuth and an overview of its workings. If you want to dive deeper, here are some resources:

https://oauth.net/2/
https://developers.google.com/oauthplayground/
https://marktrapp.com/blog/2009/09/17/oauth-dummies/