"Or Login with Your Google or Facebook Account."

The fact that you can use a single login to access most of your favorite go-to sites is a luxury that, while simple, has dramatically changed the way we interact with businesses online.

Ditching hundreds of usernames and passwords is just one example of the incredible impact OAuth - specifically OAuth 2.0 - has had on the digital landscape.

Think about it: at their core, online banking, social media, online shopping, email, video conferencing, and GPS navigation are all different forms of data and information exchange.

Much of the data you trust to the internet is personal and highly sensitive. The success of the entire system depends on having a reliable way to control access to private data and ensure it is protected from unauthorized entities.

OAuth 2.0 is a critical facilitator of internet activity, but it's not well understood outside a small subset of specialized developers.

What Is OAuth?

OAuth 2.0 is an open-standard authorization framework that allows unrelated services to safely permit authenticated access to their assets without sharing some critical central credentials — i.e., the owner's password.

OAuth works on the principle of granting permission to access data rather than providing proof of identity, meaning it is an authorization protocol rather than an authentication protocol.

Users delegate exactly what personal information will be revealed. OAuth works over HTTPS, authorizing servers, devices, APIs, and applications. Instead of passwords, it uses short-term access tokens.

To better understand the purpose of OAuth, you might consider this often repeated analogy of a valet key. Many of today's luxury cars come equipped with a special key to be used only by a parking attendant.

Unlike your standard key, the "valet version" will start the car but denies access to certain areas of the vehicle like the trunk or glove box. Nor will this key allow the vehicle to be driven more than a short distance - with speed maximums also regulated.

Working on the valet key principle, OAuth allows you (the user) to grant limited access to your private resources to a third-party website without sharing your identity or password.

Read More: What is API Security and Why It's Important

Why OAuth Became the Industry Norm

Until late 2007, there was no open standard for API access designation. To connect with a website, you'd need to provide your user name and password. So far, so good. But if another site were involved in the mix, which often happens, the second site would need them, too.

Giving up your password to a separate set of hands is not only tedious but risky. Now the odds your secret could fall to the wrong person have exactly doubled. 

Fortunately, OAuth 1.0 and now 2.0 can eliminate the need for a do-all password and restrict these sites to necessary functions. 

In more practical terms, beyond the single sign-on example above, OAuth is what makes it possible to easily complete actions like posting pictures and videos from your phone to social media and paying for online purchases using your Amazon account instead of entering your credit card information. 

You see OAuth in action every time you grant permission for an app to access the camera on your phone or allow a browser plug-in to access your Google account. Basically, the list of OAuth-related functions that make our lives easier is exhaustive.

Read More: API Terminology: A Complete List of Terms for Beginners

OAuth 1.0 vs OAuth 2.0 

These days, when developers speak of OAuth, they mean OAuth 2.0. In fact, the iterations differ so widely that they're incompatible. The programs can be operated separately, though that's become increasingly rare. 

To understand the distinctions, some clarification and history may be helpful.

In late 2007, OAuth 1.0 arrived on the scene with a framework based on digital signatures. It was reliable, secure, and quickly accepted by players such as Google and Twitter. The drawback: OAuth 1.0 meant crypto-implementation and crypto-interoperability, a challenge for many developers. 

OAuth 2.0, released in Oct. 2012, was a totally different animal. This newer version wasn't backward-compatible with OAuth 1.0 or 1.1, and crypto was no longer part of the system. 

OAuth version 2.0 relies on access tokens to circumvent the need for passwords, making authorization much easier and more flexible - and also more interoperable between sites and devices.

Superseding its predecessor, OAuth 2.0 has become the go-to solution for many companies, including Facebook, Microsoft, Twitter, Google, and Mozilla.

To summarize the differences:

• OAuth 1.0 used complicated crypto graphics, supported only three flows, and did not scale.
• OAuth 2.0 has six flows for various needs and applications and enables signed secrets over HTTPS. OAuth 2.0 tokens need not be encrypted on the endpoints but are encrypted in transit.  

Read More: What Is OWASP API Security Top 10 & Why It's Important

How It Works: The Building Blocks of OAuth 2.0

Before addressing the individual components, let's look at the sequence of events when a user initiates a website action that involves another unrelated site or service. It's assumed that the user has signed in to the first site using HTTPS.

1. Site A uses OAuth 2.0 to connect with site B, providing the user's verified identity.
2. Site B issues a one-use request token, along with a unique secret.  
3. Site A sends the token and the secret to the user's client software.
4. The client software sends the request token to the authorization provider (OAuth's main engine). 
5. If, for any reason, there’s been no authentication to the provider, the client is asked to approve the authentication to site B.
6. The user (or the user's software) approves a specific type of transaction on-site A.
7. The request token now becomes an approved access token and is awarded to the user.
8. In turn, the user gives the approved access token to site A.
9. Site A now gives the access token to site B. This demonstrates proof of authentication.
10. Site B (at last) allows site A access on behalf of the user.
11. Mission accomplished.

The discussion of how OAuth 2.0 works can easily become highly technical. At a high level, the basic building blocks and their functions fall into five central components.

1. Scopes and Consent
2. Actors
3. Clients
4. Tokens
5. Flows

Now, let's break down each of the components in greater detail.

1. Scopes and Consent

Scopes are mechanisms that define permissions and set boundaries for what an application or service does or does not have access to.

When an app sends an authorization request, the user is presented with the specific scope of the request and must authorize consent. 

This consent serves as proof of authorization and allows an access token to be granted.

2. Actors

There are four actors appearing in an OAuth flow:

• The resource owner owns the data for which access is requested. The resource owner can be an individual end-user or a company. Circling back to our valet key analogy, you are the resource owner of the luxury car.
• The resource server is the API or server that securely stores the data the application or service has requested to access. The resource server must accept and validate an access token from the requesting application to grant access to the data. In our analogy, the resource server is the car's computer that verifies the validity of the valet key.
• The client is the application or service requesting access to the data the resource server is protecting. Clients gain access to the requested resources by presenting a valid access token to the resource server. Again, using our analogy, the client is the valet attendant who's requesting to move the car.
• The authorization server handles token management and is, therefore, where most of OAuth takes place. Access requests from the client are directed to the authorization server. Once the resource owner has seen the scopes and provided consent, the authorization server issues a new access token to the resource server.

3. Clients

Clients can be either confidential or public. Confidential clients are what the name implies — they keep secrets. They run in safe areas and can't be accessed by end-users.  

Public clients are less secure entities such as browsers, mobile apps, and IoT devices, while confidential clients are more secure and can be granted more access to secure resources.

4. Tokens

There are two types of token actors in OAuth flows — access tokens and refresh tokens.

• Access tokens are granted by the authorization server and used to access the data in the resource server. They typically allow clients to access resources for a few minutes up to a few hours.
• Refresh tokens are only granted to confidential clients with secure authentication protocols and can be valid for days, months, or even years - they can also be used to get new access tokens for other clients.

When you kill a refresh token, you get a new, cryptographically signed access token.

Typically, these are formatted in JavaScript Object Notation (JSON) and are known as JSON Web Tokens, or JWTs (pronounced "jots"). JWTs allow digital signatures (also known as claims), which can be later verified with a secret signing key.

Tokens are retrieved from two primary endpoints on the authorization server. First is the "authorize endpoint" that grants user consent and authorization. The authorization then passes to the "token endpoint," where the grant is processed and both the refresh token and access tokens are awarded.

The access token is the key to accessing the APIs. But once expired, it takes another trip to the token endpoint, with the refresh token, to do it all again.

5. Flows

Flows are the series of steps and authorization grant types required for clients to access the requested resources. 

OAuth 2.0 includes six flows intended for different types of interactions.

• Implicit flow involves granting short-term access tokens to public clients.
• Authorization code flow is the most secure flow and uses a combination of authorization code grants and access tokens.
• Client Credential Flow is meant to handle server-to-server access requests from confidential clients.
• Resource Owner Password flow is rarely used and not recommended for most use cases.
• Assertion Flow is similar to client credential flow and makes allowance for the use of federation.
• Device Flow handles access requests made via a smart device such as a TV screen.

Potential Downsides of OAuth 2.0 or Why It's Not Enough to Secure Your APIs

As welcomed as OAuth 2.0 has been by developers and end-users for protecting private data, there have also been detractors. 

Some have slammed the severe changes between versions 1.0 and 2.0, not without reason. OAuth 2.0 is significantly less secure than its predecessor and more complex. 

The greatest criticism of OAuth2.0 may be that it doesn't directly support client verification, signature, or channel binding.

Detractors charge that OAuth 2.0 creators chose to concentrate on increased interoperability between sites and devices rather than provide additional range and security.

OAuth has suggested using a third-party protection protocol such as Transport Layer Security (TLS)  to provide the additional features.

While OAuth 2.0 is a step forward in the safe use of private data, it's nowhere near enough to protect your API from broken object-level authorization (BOLA) vulnerabilities that rank #1 in the OWASP API Security Top 10 list.

Companies rely on automated API security testing platforms to comprehensively test their APIs to keep up with ever-evolving security standards.

APIsec provides just that by leveraging the power of AI to test your APIs across a wide range of vulnerabilities automatically.

The setup process takes minutes (not days or weeks), allowing you to save countless hours of your highly-paid developers while completely eliminating human error from the equation.

Are you looking to see APIsec in action? Reach out to our team today for a free security assessment.