Open Authorization (OAuth) is an open standard designed to allow a website or applications to access resources hosted by other web applications on behalf of a user. It plays an important role in efficiently balancing the need for convenience, security, and privacy.
What’s the point of it?
Convenient access to online resources using a username and password comes at a price. It’s simple, but it can also limit privacy and compromise security.
For example, let’s say your accounting firm 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.
In this article, we’ll look at OAuth, covering the following key aspects:
- How OAuth works
- Why OAuth is important
- What OAuth integrations are possible
- How you can integrate OAuth into an API environment
- How Kong Gateway offers effective OAuth integration
What is OAuth (and what is it not)?
Before going further, however, it’s important to understand what OAuth is not.
- OAuth isn’t a single sign-on, federated authentication system like Microsoft’s Active Directory Federation Services, Google Account, or GitHub integration.
- OAuth 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 is a standard for building an authorization mechanism that will provide secure, delegated access using HTTP connections.
Let’s go deeper by considering an example.
A simple OAuth example
Let’s return to our accounting organization and its customers.
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. And this is what OAuth provides.
Why use OAuth?
You don’t want to build the complex infrastructure needed to authorize third-party services to access your customers’ data. This is because getting an authentication mechanism right can be tricky and very expensive if not done correctly. Also, it’s generally best to limit the use of username/password combinations whenever possible.
The OAuth standard, when properly implemented, 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.
You’ve probably seen OAuth in action without even realizing it.
When you sign in to a website or app using your Facebook login, the app (or website) is using OAuth to authenticate your account. OAuth lets the app access your basic information from Facebook, including your name, profile picture, and email address. The app can then use that data as part of your user experience without handling or storing your credentials.
Facebook, Google, GitHub, LinkedIn, and Amazon can all handle authenticating your credentials on behalf of third-party applications.
How does OAuth work?
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, 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 OAuth authorization flow
The authorization flow generally works as follows:
- 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).
- The client application redirects the user’s browser to the authorization server (in our example, this is also the accounting firm’s website).
- The authorization server displays a login page for the user to enter their credentials.
- 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.
- The client application exchanges the authorization code for an access token and a refresh token from the authorization server.
- 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 it has 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 that are 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.
What is OAuth 2.0?
You may have seen references to OAuth 2.0, which implies that there once was an OAuth 1.0.
Indeed, when OAuth 2.0 was introduced in 2012, it represented a complete reworking of the authentication process. The 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).
How APIs can use OAuth
Organizations 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 your accounting firm allows customers to grant authorization to their resources from within the tax authority’s mobile app on their phone. Your 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.
OAuth vs SAML vs OpenID
Security Assertion Markup Language (SAML) is a widely used standard for authentication. 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.
OpenID is also an identity provider since it allows users to extend their authenticated identities (like a Google account login) to other services (like YouTube).
As we’ve seen, OAuth is an authorization standard and doesn’t manage authentication directly. 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.
Introducing Kong Gateway
Using token-based authorization mechanisms to grant users access to different enterprise applications is critical for maintaining security. In today’s fast-paced, competitive business landscape, the seamless transfer of information between applications, microservices, and APIs brings high value and is a high priority.
- 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