OAuth 2.0 and OIDC

This chapter is going to get you started on the technical journey to understand the advanced concepts that will be covered in the following chapters.

In this chapter, we are going to learn about the basics of the most used authentication protocol for cloud applications, which is OAuth 2.0, and we are going to appreciate why OAuth 2.0 has become the de facto standard in web authentication.

This chapter will also introduce you to OpenID Connect (OIDC).

OIDC extends the OAuth 2.0 protocol by introducing new flows, reusing some existing ones, and making the user, not the application, the center of these flows.

In this chapter, we will go through and learn all about the basics of OAuth 2.0 and OIDC, their similarities and differences, where they can be used and why, and what the actors that participate in authentication and/or authorization flows are.

This chapter will not analyze the flows of these protocols in depth; those will be covered in the next...

OAuth and OIDC basic concepts

The basic architecture of applications that are composed of multiple tiers separating the presentation from the business logic and data, with the business logic exposed through a set of services, has largely gone unchanged for the last decade.

However, the environment in which these applications are expected to operate has completely changed in this same timeframe. Today, you cannot just offer a simple browser-based website; you need to also support IoT devices (such as presentation screens, smart devices, sensors, and electrical appliances) and mobile clients, and these mobile clients must be supported across a broad range of devices, mostly based on iOS, Android, or Windows.

In today’s landscape, users expect applications and services to interoperate – to be able to be used together. For example, users expect to be able to post the latest purchase they have made from Amazon or ASOS to their Facebook wall or share a photograph on Instagram...

How OAuth and OIDC work together

Despite OAuth being commonly used together with OIDC to cover both authentication and authorization requirements, it is not mandatory for them to be used together. Just to provide an example, OAuth can be used for authorization even in contexts where another protocol (for example, the SAML protocol, described in the Security Assertion Markup Language section in Chapter 1, Walkthrough of Digital Identity in the Enterprise) is used for authentication. As a matter of fact, the specification of OAuth does not include OIDC, which can be seen as an optional layer to add.

Let’s use a concrete example to better understand the usage of the OAuth protocol without any authentication flow. OAuth is the protocol that is used by Facebook when a user needs to access a third-party application (for example, Spotify) with their Facebook account. In this context, the user is usually already logged in to the Facebook platform and they are just prompted to grant...

How the protocols are implemented in the real world

It is important to note that both OAuth 2.0 and OIDC are standards supported by a number of services, including Azure Active Directory, OWIN and Katana, NetIQ Access Manager, Google Authentication, and PingFederate, just to mention a few.

Generally speaking, as they are the de facto standard, a developer who wants to implement an OAuth/OIDC flow for their application doesn’t necessarily need to know the specification in depth and apply custom code to their solution. Client libraries, generally grouped into frameworks, that implement these protocols can be found in the most widely adopted programming languages to ease the development of an application that implements these standards.

The following is a non-exhaustive list of technologies that enable developers to take advantage of either commercial or non-commercial libraries to implement authentication/authorization through OIDC/OAuth:

• ActionScript
• C
...

Technical background

Before diving deep into flows, it’s important to understand some basic concepts regarding the actors that participate in the authorization or authentication process. If you are familiar with other protocols, you will appreciate that the concept is not so different.

Let’s start with the basics by trying to understand what the actors, devices, and servers involved in an OAuth 2.0/OIDC flow are and what their role during the authentication and authorization process is.

These are the main parties involved in nearly all protocol exchanges. The following diagram summarizes all of them:

Figure 3.2 – OAuth/OIDC parties

The preceding diagram shows the typical parties involved in authorization/authentication flows. The following are descriptions of each of the roles reported in the diagram:

• Resource owner: This is the entity that allows access to the final resource (the resource server). If this entity is a human...

Summary

In this chapter, we reviewed the analogies and differences across OAuth and OIDC. We understood OAuth and OIDC to be authorization and authentication protocols, respectively. These protocols share the same flows and logic.

OIDC is defined as an authentication protocol that runs on top of OAuth. This is because the flows adopted are the same.

We also familiarized ourselves with the terminology needed to understand the OAuth 2.0/OIDC flows that we will cover in depth in the next chapter, and the patterns that will be discussed in a later chapter.

This chapter provided the basis to understand these protocols and their related flows better. In the next chapter, we are going to view how these concepts are implemented and look at OAuth flows in much more detail.