Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
  • Overview
  • Transcript

1.2 Understanding OAuth

In this lesson, I’ll give you a high-level explanation of OAuth. We’ll start with what OAuth is and why we use it. Then we’ll get into some theory and terminology behind OAuth, with visuals and examples. Finally, I’ll run you through the flow of authorizing via OAuth between two sample applications.

Related Links

1.2 Understanding OAuth

[SOUND] Hello, and welcome to this Tuts+ Coffee Break Course on understanding OAuth. In this course, we'll go over what OAuth is and why it's used, and then we'll do a step by step run through a sample OAuth integration between two web applications. So let's go ahead and start with, what is OAuth? OAuth is a standard for how you can authenticate and authorize both users and applications in a way that's secure, through taking steps that developers are familiar with. It's important to note the difference between authentication and authorization. Since they both start with A-U-T-H, they're typically lumped together and referred to as auth, but they are each distinct concepts that are handled differently in an application. You may not think about it consciously, but you actually work with authentication and authorization all the time. When you login to a web app, let's say an online banking app, it checks your login credentials, which is a username and a password. If your login credentials are correct, you're allowed in. That's the authentication piece. However, once you're in, you're not necessarily allowed to do everything that the app is capable of. For instance, the online banking app may have a feature where you can add a credit to someone's bank statement. But any random consumer with a bank account isn't allowed to do it. You have to be logged in as a bank employee to do that. As a normal user, you won't see the button to add a credit. And if you happen to know the endpoint that the button talks to when you press it, you'll get an error from the server. That's authorization. Now, we mentioned that OAuth is a standard. The standard is actually defined in a 75-page document by the IETF called RFC 6749. It's heavy reading, but it's worth having a look at. Basically, OAuth is collection of standards and conventions that can be implemented in any programming language, however you see fit. As long as it conforms to the requirements outlined in the RFC. The requirements describe pieces of information, the format of that information, and the flow of the information between all the different parties involved that are authorizing through an OAuth implementation. One of the key concepts behind OAuth is that it's not just the users who are getting authenticated through login credentials. In an OAuth set up, we have credentials that applications have as well. And we have to think about whether or not an application is allowed access and what they are and aren't allowed to do. When an OAuth integration happens, you typically have three major parties involved, the resource server, the resource owner, and the client. A good way to visualize these is to think of Facebook. The resource server in this case is going to be Facebook. They're the ones hosting all the information you're trying to work with. You sometimes refer to this party as the OAuth provider, the resource owner is going to be a user of Facebook. They own the information we're trying to get access to, their user profile information, status updates, photos, all that stuff. The client is going to be a third party application that wants to integrate with Facebook, like maybe a game or another type of online service. They wanna retrieve data from Facebook to use in their own app or do things inside Facebook on the user's behalf. For example, the application could be a game like Farmville or Candy Crush, and they wanna post on the player's wall about achievements they've made in the game through Facebook's API. Facebook won't just give anyone full access, though. An app has to be registered with Facebook. And each individual Facebook user has to be logged into Facebook and approve the app first, before the app can work with their Facebook data. These types of integrations can be done without OAuth, but it's not safe. The user would have to give the application their username and password for Facebook, and it would get stored inside the application's database. If the user were to change their password, the integration would break. If the application's database were to be hacked, the hacker would have everyone's Facebook passwords, since they would have been stored in plain text. The end goal of the OAuth flow is for whoever is being authorized to have an access token, or a string of random characters, that they can pass in on every API call to show who they are and that they're allowed to do whatever they're trying to do. In OAuth, you have a few different standard flows for how authorization can happen, which are known as authorization grants. When people talk about OAuth, they're typically referring to the three-way handshake we just described between a resource server, a user, and a third party application. That type of setup is done through the authorization code grant, most likely combined with the refresh token grant. We'll be running through a sample implementation of those two grants shortly. For right now, it's worth mentioning the other grant types. The implicit grant is for the same scenario as the authorization code grants, but for cases where you can't keep the credentials hidden from the public. Like if the whole process is happening in a browser, where all the JavaScript is out in the open. There is also the password grant for logging in a user with just their username and password without an application being involved. Finally, there's the client credentials grant, which is for logging in an application without the user being involved. Now that we've covered what OAuth is and why we use it, let's run through a sample OAuth integration. We've got two web applications written in Laravel that are meant for users who read and collect books. The first one is called MyBookshelf and the second one is called WormRate. Both require a username and password to get in, and registration is free and open to anyone. MyBookshelf is for managing your personal book collection. You can add books and authors to your collection and view a list of books that you have, filtered by a particular author. I've got it running locally at MyBookshelf.app. WormRate is for people to leave ratings and reviews on books that they've read so that others can come in and read the reviews before they decide to buy the book. I've got it running locally at WormRate.app. In this setup, we have MyBookshelf as the resource server, or OAuth provider, and WormRate as the client application, or OAuth consumer. The end goal here is for WormRate to get an access token so that it can make API calls to MyBookshelf, and work with the resources that are being hosted there. In this case, it's the same one person that's got accounts on both WormRate and MyBookshelf, and we want for that person to be able to see their MyBookshelf resources while using WormRate. When you log in to WormRate and go to your home page, you'll have the option to integrate with MyBookshelf. Once you've gone through the OAuth flow and the authorization is complete, WormRate will make API calls out to MyBookshelf to pull down the list of books that you have in that system. Using the API call, WormRate compares the data from the two systems and outputs a list of books from your MyBookshelf account that you have yet to review on WormRate. Here's what it looks like when the authorization is finished. You get a list of books to review, I go in and review one, and when I go back to the home page, it's no longer in the list. Let's start over with a brand new user that hasn't been integrated yet, and we'll walk through the flow. Start by logging into WormRate. You get a prompt to integrate with MyBookshelf. If you click that, it bounces you over there. If you're not logged in already, you'll need to log in. Once you're logged in, you get this authorization prompt. Have a look in the address bar, and you'll see some query string parameters. client_id is like the application's username. The one we're using here is what's registered to the WormRate app inside MyBookshelf's database under the oauth_clients table. That's how MyBookshelf knows for which app it's supposed to show the auth prompt that we're seeing right now. The response_type of code means we want for MyBookshelf to give us an authorization code if the user approves the authorization. The redirect_uri is an endpoint back on WormRate to redirect the user to after approval. OAuth login screens like this are pretty typical. Facebook gives you something similar. Before you authorize the application to access your resources, it gives you a list of privileges that the application will be given. These privileges are called OAuth scopes. For MyBookshelf, the scopes you see here are defined under the oauth_scopes table, and assigned to the WormRate application through the oauth_client_scopes table. Looking at the oauth_client_endpoints table, we see where WormRate's redirect_uri is registered. Once we approve the authorization, we get bounced back over to the redirect_uri, which is a page on the WormRate app. But look at the address bar, they've grafted a query string param on to the redirect_uri, which is the authorization code. On this endpoint, WormRate took the code and made another HTTP request back over to MyBookshelf to activate the code. Once the code gets activated, WormRate now has an access token it can use to make calls to MyBookshelf's API, on behalf of this particular user. WormRate saves the access token as well as a refresh token onto this user's record in its users table. Every time this user loads their home page, WormRate pulls down this user's MyBookshelf books before rendering the page. That just about covers our high level overview of OAuth. You've had a chance to see OAuth in action, with an integration between two sample apps. Thanks for watching, and keep an eye out for OAuth prompts as you're using the Internet.

Back to the top