API authorization and authentication are not as straightforward as they once were. In fact, they aren’t even the same thing despite sounding virtually identical. We’ve been mentioning OAuth quite a bit lately, so it seemed like the perfect time to take a deeper look into OAuth 2.0.

To set the record straight and answer the question “What Is OAuth 2.0?” as thoroughly as possible, we’ve put together a guide to OAuth 2.0 with everything you need to know to get started with the popular API authorization format. Below, you’ll discover whether or not it’s right for you.

What Is OAuth 2.0?

Developers need to strike a delicate balance when it comes to API authorization. First and most importantly, authorization must be secure enough to protect your assets exposed by the API, which is its primary purpose. Yet, it must be simple and quick to implement. Both the API developers and consumers deserve to have their privacy respected, as well.

OAuth 2.0 was created to contend with many of these modern digital dilemmas. OAuth stands for “Open Authorization” and is an open standard protocol that allows websites and applications to securely consume APIs. OAuth 2.0 replaced OAuth 1.0 as the standard for API authorization in 2012 in response to some of the concerns raised by OAuth 1.0.

API vulnerabilities can be serious security threats, and OAuth 2.0 acts as a layer of abstraction between the client and consumer. But it’s good to realize that OAuth 2.0 is not an authentication protocol. Instead, its main function is to determine what assets are available to which users. This is accomplished using Access Tokens. For those who aren’t familiar, an Access Token is a file that stores sensitive security data string that can store sensitive security data, which is usually structured in the format of a JSON Web Token (JWT). Access Tokens also allow developers to limit how long a user can access an API.

How OAuth 2.0 Is Set Up

OAuth 2.0 flows follow a structure similar to other web communication but have some nuances. The main components are still the Client (an application); the User; and the Server. The Server is often two servers main difference is the Server is split into two parts — the Authorization Server and the Resource Server.

The Resource Server is the regular API server. It receives the request for an asset from the user and submits it to the client. On the other hand, the Authorization Server acts as an abstraction layer solely for security reasons. The user’s identity is stored on the Resource Server, which not even the client can access.

When a user requests an asset from the client, they’re given an authorization code. This authorization code is then traded for an Access Token. This approach is more secure as well as more versatile. Once the Access Token is issued, it can be easily renewed using Refresh Tokens.

How OAuth 2.0 Works

To begin, the Client establishes two credentials with the Authorization Server, known as client_id and client_secret. These are used to authorize requests once they’re approved.

A typical OAuth 2.0 flow begins with a user requesting an asset from the client. When a user requests access to an asset, the client sends a request to the Authorization server for an Access Token. They can also determine the Scope at this stage, dictating what resources are exposed and for how long. These resources can also be routed to a custom endpoint. These resources are then returned to either the /authorize endpoint or the /oauth/token endpoint.

Once the client_id and client_secret have been verified, the Authorization server will respond with either an Access Token or authorization code. Whether the Authorization Server returns an Access Token or authorization code is determined by grant types.

What Are Grant Types?

In OAuth 2.0, the steps a user must take to secure authorization are known as Grants.

Grant Types Used in OAuth 2.0:

• Authorization Code Grant: The first grant type is an Authorization Code grant, which returns a single Authorization Code which is then traded for an Access Token. Authorization Code grants are useful for typical authorization code requests, as well as for mobile apps and single-page applications using the Proof Key for Code Exchange (PKCE) technique. The PKCE technique adds an additional layer of security with the inclusion of a Code Verifier, which is then received and then translates the Authorization Code. In the event of a security breach, a cybercriminal can’t do anything with the Authorization Code without the Code Verifier.
• Implicit Grant: An Implicit Grant returns an Access Token directly to the client following an API request to a specified endpoint.
• Resource Owner Password Credential Grant: Resource Owner Password Credential Grant returns an Access Token directly, without having to redirect to the Authorization Server. This is recommended solely for clients that are completely trusted.
• Client Credentials Grant: A Client Credentials Grant typically is used for automated processes and microservices. This grant type uses the client_id and client_secret directly.
• Device Authorization: A Device Authorization flow enables resources to be consumed by devices with input constraints, like a Smart TV.
• Refresh Token Grant: A Refresh Token grant is used when a Client needs to get a new Access Token with the use of a Refresh Token.

The Difference Between API Authorization and API Authentication

Earlier, we pointed out that API authorization and API authentication are not the same thing. They’re related but distinct enough to be worthy of a bit of additional commentary. To put it in simple terms, API authentication specifies who someone is. On the other hand, API authorization determines what resources they have access to.

API authorization and API authentication are frequently mentioned as they are closely related. Generally speaking, API authentication comes first. Once a user’s identity is verified, API authorization determines which resources they can access.

To illustrate the point, imagine you buy a first-class ticket for a flight from New York to Los Angeles. The flight attendant checking passports at the boarding terminal would be the authentication. Once you’re on board, your ticket proves which seat is yours, which is akin to authorization. Your ticket is for a specific seat, which would be all you’d be authorized to access. Some flights might be first-come-first-serve, however, so the whole First Class section would be available to you, theoretically speaking.

Final Thoughts On OAuth 2.0 and API Authorization

APIs make our digital assets endlessly more useful, but they also can increase cybersecurity risks and vulnerability. APIs also raise some logistical questions that need to be addressed as we move forward into an increasingly virtual society.
API authorization isn’t just for preventing cyberattacks, for instance. It’s even more important inside of an organization as different employees require different levels of access. Imagine a sales team that wants to access customer records to put together some targeted marketing campaigns. Obviously, the sales and marketing departments would need to access a database of users’ contact information. Does that mean they should be able to access those users’ credit card or social security numbers, though? Of course not!

Specific cases like this will only become more common as the world continues to become more connected. What are the legalities of exchanging digital medical data internationally, for instance? API authorization is a simple way to tackle some of these issues while still allowing our APIs to be useful and usable.