Download code from GitHub
As an application developer, you may have heard the term OAuth 2.0 thrown around a lot. OAuth 2.0 has gained wide adoption by web service and software companies around the world, and is integral to the way these companies interact and share information. But what exactly is it? In a nutshell…
OAuth 2.0 is a protocol that allows distinct parties to share information and resources in a secure and reliable manner.
This is the major tenet of the OAuth 2.0 protocol, which we will spend the rest of the book learning about and utilizing. Also, in this chapter, we will introduce the sample application that we will be building throughout this book, The World's Most Interesting Infographic Generator.
Note
What about OAuth 1.0?
Built with the same motivation, OAuth 1.0 was designed and ratified in 2007. However, it was criticized for being overly complex and also had issues with imprecise specifications, which led to insecure implementations. All of these issues contributed to poor adoption for OAuth 1.0, and eventually led to the design and creation of OAuth 2.0. OAuth 2.0 is the successor to OAuth 1.0.
It is also important to note that OAuth 2.0 is not backwards compatible with OAuth 1.0, and so OAuth 2.0 applications cannot integrate with OAuth 1.0 service providers.
Before we dive into our discussion of OAuth 2.0, it is important to first define some terms. There are two terms in particular that are pivotal to our understanding of OAuth 2.0 and its uses: authentication and authorization. These terms are often conflated and sometimes interchanged, but they actually represent two distinct concepts, and their distinction is important to understand before continuing our discussion of OAuth 2.0.
Authentication is the process of validating whether a person (or system) is actually who they say they are.
An example of this is when you go to the bank to withdraw money, and you provide your bank card and PIN to the teller. In some cases, the teller may ask for additional identification, such as your driver's license, to verify your identity. You may recognize this in other instances when you provide your username and password to a website, say, to view a document.
Authorization is the process of determining what actions you are allowed to perform once you have been authenticated.
Referring to our previous bank example, once the teller has verified who you are, they can then proceed to fulfill your request to withdraw money. In order to do this, they must check whether you are allowed to withdraw money from the account that you are requesting (that is, you are actually the owner of the account). Relating to our website example, once you have authenticated by providing your username and password, the website will then check to see whether you are indeed allowed to see the document that you are requesting. This is usually done by looking up your permissions in some access control list.
Now that we have established the distinction between these two important concepts, we can look at what OAuth 2.0 actually is and the problems it solves.
Have you ever logged into a site using your Google account? Have you ever posted to Pinterest and Instagram at the same time? Have you ever shared a link to your wall from any application other than Facebook? These are all examples of OAuth 2.0 in use!
At a high level, the OAuth 2.0 protocol allows two parties to exchange information securely and reliably. In more practical terms, you'll find that the most common uses of OAuth 2.0 involve two things:
Allowing a user to log into an application with another account. For example, Pinterest allowing users to log in with their Twitter accounts. This is known as federated identity.
Allowing one service to access resources on another service on behalf of the user. For example, Adobe accessing your Facebook photos on your behalf. This is known as delegated authority.
Both of these combine to allow the creation of powerful applications that can all integrate with each other.
Tip
Both of the scenarios mentioned in the preceding list are actually really the same scenario. In both, the user is accessing a protected resource on behalf of another party. In the first example, the protected resource is the user's account information, while in the second example the protected resource is the user's Facebook photos. This will become clearer as we explore the details of how the OAuth 2.0 protocol handles these situations.
Federated identity is an important concept in identity management. It refers to the concept that allows one service provider to allow authentication of a user using their identity with another service provider. For instance, imagine a user that logs into Foursquare and Amazon with their Facebook credentials. In this example, the user only needs to maintain a single user account, their Facebook account, which gives them access to several service providers; in this case, Facebook itself, plus Foursquare, and Amazon. They don't need to create individual accounts on Foursquare or Amazon, and therefore, don't need to maintain three separate passwords. In this sense, the user's identities across these sites are federated, as in, they are made to act as one.
Tip
The OAuth 2.0 Authorization Framework
Strictly speaking, the OAuth 2.0 protocol is actually an authorization protocol and not an authentication protocol. Because of this, OAuth 2.0 alone cannot provide federated identity. However, when used in a certain way, and in conjunction with other protocols, OAuth 2.0 can provide federated authentication, which is a key component to federated identity systems.
See the OpenID Connect section in Chapter 12, Extensions to OAuth 2.0, to see how the OAuth 2.0 protocol can be combined with OpenID to provide an authentication layer on top of the authorization framework described by the OAuth 2.0 specification.
Delegated authority is another important concept in the identity space. It refers to the ability for a service or application to gain access to a user's resources on their behalf. Take, for instance, LinkedIn, which can suggest contacts for you to add by looking at your Google contact list. In this example, LinkedIn will be able to view your Google contact list on your behalf. Permission to access your Google contacts has been delegated to LinkedIn.
Now that we understand the basic principles of OAuth 2.0, let's take a look at some everyday, real-life examples of OAuth 2.0 in action:
StackOverflow allowing you to log in with your Google account
Posting a status update from your phone using the Facebook mobile application
LinkedIn suggesting contacts for you to add by looking at your Google contacts
Pinterest allowing you to pin something from a WordPress blog
Sharing an article to your Facebook feed from the article itself
As you can see, if you've ever done any of these things, or anything similar, you have probably already used OAuth 2.0.
In order to see how OAuth 2.0 solves this problem of sharing resources, let's look at how this problem was solved before OAuth 2.0 was created.
Imagine that you have just signed up for the service GoodApp. As a new user, you don't have any contacts. GoodApp wants to suggest contacts for you to add by looking at your Facebook friends. If any of your Facebook friends are on GoodApp, it will suggest that you add them.
Before the creation of OAuth 2.0, this was solved in a very insecure way. GoodApp would ask you for your username and password for Facebook. GoodApp would then log into Facebook on your behalf to get your friends. This interaction can be looked at like this:
You ask GoodApp to suggest contacts to you.
GoodApp responds by saying, "Sure! Just give me your Facebook username and password please!"
You give GoodApp your username and password for your Facebook account.
GoodApp then logs into Facebook using your credentials, effectively impersonating you, to request your friend list.
GoodApp then uses this information to tailor suggested contacts for you.
Why is this a bad idea? There are five key reasons:
You have given GoodApp the power to do *anything* with your account: This is known proverbially as giving it the "keys to the city". You have essentially given GoodApp access to everything in your account, as if they were you. Now imagine it wasn't GoodApp. Instead it was NewUnknownApp. It's easy to see how this becomes very dangerous.
GoodApp may save your password, and may do so insecurely: In order for GoodApp to maintain access to your account, they would need to store your credentials. The act of storing your password is an extremely bad practice and should be avoided at all times. To make things worse, different companies enforce different standards of security, some of which are shockingly low.
You are giving more chances for your password to get stolen: You are sending your username and password across the Internet. The more times you do this, the more risk there is for someone to steal it.
You have to change your Facebook password if GoodApp ever gets hacked: If GoodApp somehow got compromised, your Facebook credentials will also have been compromised. You would then need to change your Facebook password as a result of GoodApp getting owned.
There is no way to revoke access: If GoodApp was acquired by EvilCorp and started doing things that you didn't like, the only way to revoke access would be to change your Facebook credentials.
Now, let's take a look at that interaction, but this time utilizing the OAuth 2.0 protocol. In this scenario, GoodApp would "ask" Facebook for your friend list. You give permission to this by logging into Facebook and approving the request. Once the request is approved, GoodApp would then be able to fetch your friend list from Facebook on your behalf.
Let's have a look at the flow:
GoodApp says, "Sure! But you'll have to authorize me first. Go here…"
GoodApp sends you to Facebook to log in and authorize GoodApp.
Facebook asks you directly for authorization to see if GoodApp can access your friend list on your behalf.
You say "yes".
Facebook happily obliges, giving GoodApp your friend list. GoodApp then uses this information to tailor suggested contacts for you.
Why is this better? Five key reasons to contrast the five points in the previous example:
You aren't giving it the "keys to the city" anymore: Notice, in this example, you aren't giving your Facebook username and password to GoodApp. Instead, you are giving it directly to Facebook. Now, GoodApp doesn't have to even worry about your Facebook credentials.
Since you aren't giving your credentials, GoodApp no longer needs to store them: With your authority delegated from Facebook, you don't need to worry that GoodApp is storing, or even seeing, your Facebook password.
You send your password across the Internet less frequently: If you already had an active session with Facebook, you actually wouldn't need to reauthenticate with them. If GoodApp has federated identities with Facebook, you would have to send your password even less frequently.
You don't have to change your Facebook password if GoodApp ever gets hacked: This is because of the next point.
There is a way to revoke access: OAuth 2.0 provides the ability for a service provider to revoke access to a client. If GoodApp ever got compromised, or got acquired by Evil Corp, you could go to Facebook and revoke GoodApp's access.
In the previous section, we mentioned that OAuth 2.0 has become one of the most important protocols for applications and service providers today. But how important is it? Here is a short, non-exhaustive list of some of the biggest supporters of the OAuth 2.0 protocol, along with some of the capabilities that they provide:
Google: You can leverage a multitude of Google's services by interacting with their APIs via OAuth 2.0
Facebook: Facebook's social graph is accessed via OAuth 2.0 and allows users to do a tremendous amount of things, including posting to their wall and sending messages
Instagram: Instagram allows you to access a user's feed and post comments and likes
LinkedIn: Post comments, share links, and gather engagement statistics via the LinkedIn APIs
Spotify: Query Spotify's massive music catalog and manage user's playlists using Spotify's APIs
Foursquare: The Foursquare API lets you look up users and places from all over the world
There are many, many more companies that use and support the OAuth 2.0 protocol. This gives developers an enormous amount of power to create amazing applications that can leverage all of these world-class services.
The best way to learn is simply by doing it. So, to learn the concepts of OAuth 2.0, we will be building an application throughout this book that will integrate with Facebook. It will be called The World's Most Interesting Infographic Generator. It will allow a user to log in with their Facebook account, request their profile data and a list of their most recent posts, and return interesting statistics about their posting habits. You can see a working example of this application at www.worldsmostinterestinginfographic.com, or www.wmiig.com for short.
In this chapter, we took an introductory look at what OAuth 2.0 is and how it is used all around us. We discussed the benefits that this protocol gives us and even looked at the kind of adoption that has taken place in the industry. It has become one of the most, if not the most, used and adopted authorization protocols on the Internet due, in large part, to the power that it gives application developers, start-ups, and corporations alike, to share information.
In the next chapter, we will look at how OAuth 2.0 provides these benefits by looking at how OAuth 2.0 actually works under the hood. Get ready!
