Getting Started with OAuth 2.0

Terminology

In order to understand OAuth, it’s important to first understand the relevant terminology. We’ll introduce some key terms up front, and then discuss additional terms throughout the book.

Authentication

Authentication is the process of verifying the identity of a user—knowing that the user is who they claim to be.

In the real world, when a police officer asks for your identification, she’s verifying your identity by ensuring that the picture on your identification matches your likeness.

On desktop computers and on the Web, authentication is about knowing that the user at the keyboard is the owner of the account. Authentication is typically performed by asking a user for a username and password. The username represents the user’s claimed identity, and the software application assumes that if the user provides the correct password that they are indeed that user.

Federated Authentication

Although many applications have their own system of accounts (including usernames and passwords), some applications rely on other services to verify the identity of users. This is called federated authentication.

In a corporate IT environment, applications may trust an Active Directory server, a LDAP server, or a SAML provider to authenticate users.

On the Web, applications often trust OpenID providers (such as Google or Yahoo!) to handle the authentication of users. There are many benefits to federation for both application developers and users. OpenID is the most common open web protocol for handling federated authentication.

Although OpenID has been used on the Web for many years, we’ll discuss only OpenID Connect, which is the next-generation version of OpenID based on OAuth 2.0.

Authorization

Authorization is the process of verifying that a user has the right to perform some action, such as reading a document or accessing an email account. This typically first requires valid identification of the user (authentication) in order to check whether the actual user is authorized.

When a police officer pulls over your car for speeding, she first authenticates you using your driver’s license (to verify your identity) and then checks the license (expiration date, restrictions, etc.) to ensure you’re authorized to drive.

The same process happens online—a web application first verifies your identity by logging you in, and then it ensures that you access only the data and services you’re allowed to, typically by checking an access control list for each operation.

Delegated Authorization

Delegated authorization is granting access to another person or application to perform actions on your behalf.

When you drive your car to a classy hotel, they may offer valet parking. You then authorize the valet attendant to drive your car by handing him the key in order to let him perform actions on your behalf.

OAuth works similarly—a user grants access to an application to perform actions on the user’s behalf and the application can only perform the authorized actions.

Roles

There are several key actors in the OAuth protocol flows:

Resource server

The server hosting user-owned resources that are protected by OAuth. This is typically an API provider that holds and protects data such as photos, videos, calendars, or contacts.

Resource owner

Typically the user of an application, the resource owner has the ability to grant access to their own data hosted on the resource server.

Client

An application making API requests to perform actions on protected resources on behalf of the resource owner and with its authorization.

Authorization server

The authorization server gets consent from the resource owner and issues access tokens to clients for accessing protected resources hosted by a resource server. Smaller API providers may use the same application and URL space for both the authorization server and resource server.