Introduction

Welcome to the second part of the Identity and Access Management (IAM) trilogy. Today we will dive deep into the best practices of the two industry standard protocols called OAuth 2.0 and OpenID Connect (OIDC). The two protocols are very similar to each other, but still highly complex on a technical level. Many of you have used one or the other at some point.

There are a lot of tutorials regarding this topic, especially OAuth. However, a lot of them contain a lot of jargon and false information. There are two reasons for this. First, it really is a complex topic and requires some background information about how the browser works and what authentication and authorization are. Second, the protocols have a lot of different ways for implementation, which makes it hard to deliver a good tutorial that covers most aspects of the technology. I've tried to keep it on a high level while still maintaining accuracy and precision to make this article useful for both software developers and laymen that have never worked in software development.

Prerequisites

• Authentication and Authorization

A Small Trip Down Memory Lane

Authentication has been an important topic in software development since the dotcom boom, and it didn't stop since then. However, the identity use cases back then were only to login a user via a simple login form, persist the session with a cookie and maybe even to have a single sign-on across multiple sites if there were multiple applications with the same users.

This could be managed pretty well with building your own authentication and authorization systems, but it got more complex as technology advanced further. After the release of the smartphone in 2007, new problems arose and people started to think about how to manage users in a simpler and more efficient way.

1. With the invention of the smartphone, we needed a way to log users in on mobile devices. Those devices more often than not could not save cookies, which means there had to be another solution.
2. As apps became more interconnected with each other, there had to be a way to transfer user information from a third party app.

Those use cases were new and in response to that, the OAuth 2.0 protocol got invented in 2012 (there was a version 1.0 released in 2007 with limited capabilities). Practical examples are:

• A photo editing app wants permission to access a user's Google Drive files.
• A CI/CD tool needs to push to a GitHub repository on your behalf.
• A backend service wants to fetch data from an API using a machine-to-machine token (Client Credentials flow).

OAuth 2.0 In Its Core

So we know that we need a new protocol enabling us to check if a user is authorized to do certain things. Let's take a look at how the protocol actually works. To make the example really understandable, let's say the third-party application is our photo editing app requesting access to a user's Google Drive files.

First things first, the photo app requests access to some resource from the OAuth 2.0 server. This is where the user gets redirected to the OAuth server, which is also called the authorization server. The authorization server does not hold the requested permission our photo app has requested. Its sole purpose is to verify the user is who he says he is. The user enters his credentials in the authorization server frontend. After he clicks submit, Googles OAuth server returns an access token to the client (if the credentials match a database entry).

The access token can then be used to make a request to the Google resource server, which holds the data our third party application wants access to. So we make a request to the resource server with our access token, the resource server checks with the authorization server if the token is valid and if it is, it returns the requested resource.

Of course there is a lot more to it, but this is pretty much how it works on a high level. There are of course more security checks. For example, the authorization server also checks the scope of the requested data and if the requested resources are in scope with the consent of the user. If everything checks out, the requested resources, in this case files from Google Drive, are returned to our photo editing app.

Limitations of OAuth 2.0

That's all good and well, but there is one small problem we didn't address so far. OAuth is only designed with authorization in mind. It should not be used for authentication. We learned the difference between those two in my previous blog post, but in a nutshell, authentication answers the question "Who are you?" and authorization answers the question "What are you allowed to access?".

As I said, as long as we stay with authorization, OAuth is fine. This also matches our use case in our example with the photo editing app. The only thing we need is permission to access files from Google Drive. No more, no less.

But there is another very popular use case. Imagine that we would not only want to access the files on the drive, but to actually sign-in with our Google account to our app. You can even see this in action on all apps having a button "Sign in with Google", or something similar. In this case, we don't want to authorize the user anymore, but to authenticate him, which means we will also need some user info to save into our database, like name, email, and so on. That's where OpenID comes into place.

Meet OpenID Connect

OAuth revolutionized authorization very quickly, so much that some people overused the protocol because there wasn't something better available at the moment. For that reason, organizations used OAuth even for the authentication of users for a pretty long time. This required some hacks and workarounds, and it certainly was not within best practices they should have been. But until OpenID released in 2014, there was no other solution. This changed with the release of OpenID Connect.

In essence, OpenID provides an additional identity layer on top of OAuth 2.0, enabling clients (websites or applications) to verify the identity of a user. Where OAuth 2.0 governs access to your data, OpenID established your identity based on the access granted by OAuth 2.0.

However, OpenID is not its own protocol, which is a common misconception. It actually sits on top of OAuth 2.0, extending its capabilities with an additional scope parameter called "openid" when making the first request from the client to the authorization server and a new endpoint on the resource server called "/userinfo", that returns the userinfo of the user making the request.

Conclusion

I hope you gained valuable information on how IAM works across applications. It is pretty simple once you understand the big picture. OAuth 2.0 is responsible for authorization across third party applications and OpenID Connect adds a layer on top of OAuth 2.0, extending the protocol with authentication.

In the last part of the trilogy we will take a good look on what to do when the user has logged in and how we can store the session in the most secure and efficient way possible.