What is OAuth?

OAuth is an open standard designed to allow a website or application to access resources hosted by other web applications on behalf of a user. It plays a crucial role in balancing convenience with security and privacy. This standard is used for building an authorization mechanism that provides secure, delegated access using HTTP connections.

It allows users to share data from one application or website with another third-party without sharing their username and password or giving the third-party direct access to the accounts. This ensures (among other things) that if the third-party application gets hit by a security breach, your credentials are still safe and sound.

Facebook, Google, GitHub, Twitter, LinkedIn, Microsoft, and Amazon (among others) can handle authenticating your credentials on behalf of third-party applications.

You've likely seen OAuth in action without even realizing it. Examples of OAuth in use include:

• Giving Spotify permission to post to a social media account on your behalf

• Granting a digital picture frame app permission to get the latest pictures from your Google Photos

• Logging into a food delivery site using Facebook rather than creating a new username and password

These examples show how a (relatively) time-consuming process that could create friction in the user experience is streamlined.

Only certain permissions are granted and these are clearly spelled out typically with phrasing around what the third-party app or service can access or modify. Once you give it the green light, the third-party app can then use that data as part of your user experience all without ever having to handle or store your sensitive credentials.

In these scenarios, the user gets a better experience, and the developers and organizations creating the service or site minimize security risks.

Much of the above might make it sound like OAuth is an API authentication service, but thats not exactly the case.

OAuth is more about authorization or checking to see what permissions or privileges a user has to access resources. Asking for a username and password or using a phone as a token is authentication or confirming identity.

For a simple simile, consider the following: authentication is showing your ID to get into an airport while authorization is what allows you to access some areas and not others.

The process of authentication is handled by the application or site serving as the identity provider (that is, Google, Facebook, or whatever it might be in the scenario).

As an authorization standard, OAuth doesn't manage authentication directly. But it can give already-authenticated users access to appropriate resources. OAuth may be configured to delegate access in sync with authentication and identity provider tools.

OAuth and single sign-on may sound similar, but OAuth is not a single sign-on, federated authentication system like Microsoft's Active Directory Federation Services, Google Account, or GitHub integration. (However, OAuth is regularly used to pass along authorization to an application from an SSO service.)

OAuth also isn't an authentication API like Pluggable Authentication Modules (PAM), nor is it an identity provider like OpenID Connect. However, OAuth can work with any of these.

OAuth and SAML are protocols both often used in single sign-on (SSO) . . . but for different purposes. While OAuth is focused on authorization or the privileges and permissions side of the equation SAML (or Security Assertion Markup Language) is focused on authentication or identification.

SAML is a widely used open standard for authentication it allows for the exchange of authentication data between an identity provider and a service provider. To put it simply, SAML is a method for apps or services to confirm you are who you say you are.

SAML is not the same with SSO, but it makes SSO possible.

The SAML specification defines three roles:

• A principal the user trying to access an application

• An identity provider (IdP) the SSO service that stores, manages, and confirms a digital identification

• A service provider (SP) the app or service the user is (uhh) using

When interfacing with service providers, identity providers can leverage SAML authentication. SAML can also be used for more complex environments like intranets, where a one-time authentication process can let users access multiple services.

Similarly, OAuth is not the same as OpenID, an identity provider that allows users to extend their authenticated identities (like a Google account login) to other services (like YouTube).

You may have seen references to OAuth 2.0, which may lead you to deduce that there once was an OAuth 1.0. (You're a regular detective Benoit Blanc, you are! But seriously, you're right.)

OAuth 2.0 is the latest version of OAuth and its a total rewrite of OAuth 1.0 The two aren't compatible, and OAuth 1.0 has been deprecated.

When OAuth 2.0 was introduced in 2012, it represented a complete reworking of the authentication process. This new version was easier to implement, distinguished between resource delivery and authorization, and supported a much wider range of devices (rather than just traditional web browsers). These modifications were the result of lessons learned from OAuth 1.0 and through discussion from major players, including Microsoft, Google, Facebook, Twitter, and Intuit.

For the user able to more quickly access a site or service, convenience is the most obvious benefit of OAuth.
For the business, fewer hurdles to complete a transaction can mean more deals closed. And for developers, it ensures users' sensitive information remains secure. (Businesses that like not losing business tend to appreciate that too.)

As a bonus, it brings simplicity along with security. You don't want to build the complex infrastructure needed to authorize third-party services to access your customers' data, at least we assume you don't. Getting an authentication mechanism right can be tricky and expensive if it's not done correctly. Also, its generally best to limit the use of username/password combinations whenever possible.

When properly implemented, the OAuth standard lets you outsource the authentication process to one or more services that have the resources to apply enterprise-grade best practices from end to end.

Convenient access to online resources with a username and password comes at a price. It's simple, but it can also limit privacy and compromise security.

As an example, let's say you work for an accounting firm that wants to allow customers to make their financial records available to government tax authorities. One option is to create credentials that the tax authority can use to access your customer's documents. But that means building an entire software module with a solid authentication and authorization process. That also assumes the government would use your site the way you want them to. (Don't hold your breath.)

One possible solution? OAuth.

Suppose the financial documents live in a highly secure backend server, accessible by your internet-facing web server and the accounting application hosted on that server. Your customers need to be able to authorize the government tax service to access their financial documents on their behalf. However, you also need to authenticate that tax service each time it tries to access financial documents on behalf of the customer. This is what OAuth provides.

To understand exactly how the standard works, let's familiarize ourselves with some key terms.

• The client is the user (or entity) requesting access. In our example above, that would be the tax authority service that wants to access financial documents on your customer's behalf. As a rule, the client interfaces with the resource provider through a web browser.

• The resource owner is your accounting customer since they own and control the financial documents. In OAuth terms, the financial documents are the resources.

• The resource server is the web server that your accounting firm is running.

The authorization server is the service that provides an authentication token that will permit the client to access the appropriate resources from the resource owner. It's common practice for the authorization server and the resource server to be the same though this kind of setup isn't always the case.

The authorization flow generally works as follows:

1. The user logs into the client application (the tax authority service), which then requests access to resources (financial documents) at the resource server (accounting firm website).

2. The client application redirects the users browser to the authorization server (in our example, this is also the accounting firms website).

3. The authorization server displays a login page for the user to enter their credentials.

4. Once the user has authenticated their identity and authorized the client to access their resources, the authorization server redirects the browser back to the client application while also providing an authorization code.

5. The client application exchanges the authorization code for an access token and a refresh token from the authorization server.

6. The client application presents the access token to the resource server for all future requests to access resources on behalf of the user.

An access token is simply an opaque string of characters. A client application uses an access token to show the resource server that its been authorized to access certain resources.

The authorization server configures how long an access token can be used before it expires.

When a client application receives an access token, it also receives a refresh token. When an access token expires, the client application can present this refresh token to the authorization server to request a new access token.

Keep in mind: not just any client can try to seek authorization to access resources. The authorization server maintains a list of clients allowed to request authorization via OAuth.

In our example, the tax authority service would need to have an agreement with your accounting firm. The authorization server grants a client ID and secret to each client that is allowed to connect with OAuth. This information is used to authenticate the client when it requests an authorization code or an access token.

Organizations and developers can add programmatic functionality to their resource access without losing the added security of an OAuth system.

For example, we can imagine a scenario in which our accounting firm allows customers to grant authorization to their resources from within the tax authoritys mobile app on their phone. The accounting firm can integrate OAuth into an API.

The new API will open an endpoint to generate OAuth authorization codes and access tokens. This endpoint will need to accept the client ID and client secret as parameters. Tokens will then be returned to the API endpoint caller as a parameter.

Using token-based authorization mechanisms to grant users access to different enterprise applications is critical for maintaining security. In today's landscape, the seamless transfer of information between applications, microservices, and APIs brings high value and is a high priority.

Kong Gateway has a rich plugin ecosystem that enables it to address common authentication, security, analytics, and monitoring requirements.

• Integrate Kong with third-party OAuth 2.0 authorization servers

• Add OAuth 2.0 authentication to your service

• Integrate Kong with a third-party OpenID Connect provider

Looking to get started with Kong and OAuth? Check out this tutorial or request a demo to learn more.