Cloud Native Data Security with OAuth

Chapter 2. OAuth 2.0 Distilled

In this chapter, we explain the main design principles behind OAuth 2.0. Remember that we use OAuth and OAuth 2.0 interchangeably, which means that we always refer to the OAuth 2.0 authorization framework as released in RFC 6749. We provide an overview of the main behaviors for applications on how to get, refresh, and revoke unforgeable API message credentials—access tokens. These tokens are the key to access protected data in APIs.

It can be hard to get started with OAuth because there is a lot to digest. Hence, if you are new to OAuth, read on to learn the most important basics. Feel free to skip this chapter if you are familiar with the framework. We provide practical guides in other chapters that show you how to work with OAuth in your APIs and in frontend applications.

The core of OAuth’s design is a mechanism for obtaining the access token. To implement the framework, you need a component, called the authorization server—a specialized piece of software that, among other things, issues those access tokens. The authorization server is one of four roles in OAuth.

Roles

The framework defines four main roles involved in any flow:

Resource owner

The entity granting access to resources, typically a user

Resource server

The entity hosting the protected resources, typically a backend API

Client

The application calling an API with an access token

Authorization server

The entity that authenticates the resource owner and issues access tokens ...