If you want to create secure APIs, you have to know about OAuth2. OAuth2 (an evolution of the original OAuth) is the current standard in API security, providing a framework that funnels API users into a particular set of authorization workflows. Below, we’ll describe the simplest version of the OAuth2 workflow and provide a few resources to help you implement it.
OAuth2’s flexibility is a key reason it’s become the Internet’s standard authorization framework. If you’re a savvy developer, there are a lot of decisions you can make as you define your OAuth2 workflow, trading security for simplicity or vice-versa. But all OAuth2 workflows contain some form of information exchange between four parties: the Client, the Resource Server, the Authorization Server, and the Resource Owner.
The Client is the third-party application making a request of your API. But before the Client’s allowed anywhere near your actual API or other resources (stored on the aptly-named Resource Server), it has to get authorized. This is where the Client goes through the authorization process that, in our previous post, we likened to checking in to a hotel. Before you can get in to the hotel, you have to get past the concierge.
The Authorization Server acts as our concierge. It takes the Client’s credentials, whether it be an API key, a username and password, or a Facebook account, verifies them, and returns a token that gives the Client access to a defined subset of the functions available through your API. This might sound simple, but actually implementing authorization can be tricky. For the most part, how you authorize users is going to depend on where they’re accessing your API from. For example, if you imagine that Clients will mostly access your application and APIs via mobile apps, there are some additional restrictions and workflow considerations to take into account that largely don’t apply to native web authentication.
You can find a lot more information on implementing authorization and understanding OAuth2, including detailed info on what form of authorization to use when. If you’re going to implement authorization yourself, I’d encourage you to read up.
After the Authorization Server has checked the Client out and passed along the proper JSON web token, the Client is allowed access to the Resource Server. The Resource Server is the server that actually contains your API, and it’s important to keep it separate from the Authorization Server. For small-scale APIs, you might host both the Authorization Server and the Resource Server in the same deployment. For larger-scale APIs, you’ll definitely want to host them separately. But whether you host them separately or together, they have to function as independent entities. The OAuth2 workflow depends on it.
Here’s why. Think of the Authorization Server as a bouncer, and the Resource Server as a nightclub. It wouldn’t do to have your bouncer standing inside your nightclub, would it? If you did, you wouldn’t actually be protected from malicious patrons. For the same reason, you have to keep your Authorization Server and your Resource Server separate. If you don’t the entire authorization workflow breaks down.
Assuming you’ve implemented your workflow correctly, your Resource Server will accept the Client’s access token (provided by the Authorization Server) and trigger the final step in the OAuth2 workflow. With the Client cleared, the Resource Server contacts the Resource Owner to actually provide the Client access to your API. According to the official OAuth2 documentation, the Resource Owner is defined as any entity that’s capable of granting the Client access to a protected resource (i.e. your API). This could be an actual user or entity, or it could be a separate machine. Either way, the Resource Server’s touchbase with the Resource Owner is the final clearance a Client needs to access your API. After that, they’ll be able to perform whatever functions their access token authorized them for.
There’s obviously a lot to unpack within that breakdown above, and I’d encourage you to read all the included links if you’re serious about implementing OAuth2 workflows on your own. If implementing OAuth2 seems a bit daunting to you, you might want to invest in an API management platform that can handle security for you (like Thriftly largely does). API security is important, but it doesn’t have to be a headache.
You’ve reached the end of our Basics of API Security series, but you can bet we’ll back to talk about security again here on the Thriftly blog. For now, we hope we’ve provided you with a basic understanding of API security, including why it’s important, how it works, and how to get started implementing it in your own APIs. If you have any questions, feel free to leave them as comments below. We'll do our best to answer them, and we might even use them as a springboard for future API security discussions.
(This post is part 4 of ourBasics of API Security series. Start reading this series from the introduction - The basics of API security.)
With Thriftly, we handle API security for you. Get started building simple, secure web APIs today with a free trial.