A Continued Analogy to Show the Need and Usefulness of OpenID Connect

I recently wrote a blog describing the OAuth 2.0 protocol using common characters in a way that’s a little more digestible than what you usually see. In researching OAuth 2.0, you’ll probably hear OpenID Connect a lot, and that it’s a protocol “built on top of OAuth.” Here, I’ll take the same friendly, digestible approach to OpenID Connect as I did with OAuth 2.0. (Check out my last OAuth Blog or this short video if you need an OAuth 2.0 refresher. Otherwise, let’s talk OpenID Connect.)

I know you might be thinking, “Another protocol? I thought we were secure with OAuth 2.0?” Well, OAuth 2.0 does a lot to add security to our apps and APIs, but its focus is on protecting the resource owner, or the end user, and their resources. OpenID Connect adds some extra assurance to protect the client.

OpenID Connect (OIDC) is a framework built on top of the OAuth 2.0 protocol to enhance its security, especially with identity management. OpenID Connect is your solution to verify who’s giving authorization to access the protected resource. In other words, OpenID Connect aims to add a way to more confidently answer the question, “Who gave authorization?”

Unfortunately, resources explaining OpenID Connect also tend to make use of diagrams in the same style as OAuth 2.0 ones: a picture flooded with arrows back and forth, names, boxes and more that make it difficult to internalize what’s really going on at the core level. Using the story from my OAuth blog involving you, grandma and the video game store, we can come up with an analogy for the OpenID Connect protocol to make it easier to grasp the overall concept and reason behind creating it. We’ll break it down each step of the way and explain it in our analogy and in the terms the protocol uses to make it easy to compare to the OAuth 2.0 protocol and what issues it tries to fix.

In case you don’t have time to read my original OAuth blog, let’s do a quick recap of the analogy we used inside of it, which we’ll continue using for this blog. Suppose your grandma has tasked you with purchasing a game for her on her store account. Grandma could just give you her username and password, but this opens a whole can of worms and security concerns. All you really need is for grandma to give the “okay” to purchase the game on her account and a way to prove that she did.

Grandma uses cryptic sticky notes that are designed for providing proof of her identity and authorization which can be decoded by her assistant. The assistant checks over your sticky note and sees that grandma is allowing you access to her account in order to purchase a game, and gives you a receipt with a barcode. Then, you’ll show the receipt at the video game store, and they can scan the barcode to prove that grandma has given you the go-ahead to purchase the game on her account.

The OAuth 2.0 protocol provides protection to the client. It separates the client from the resource owner by using an authorization server as an intermediary. In fact, the protocol states that it’s preferred for the client to ask for the resource owner’s authorization indirectly through the authorization server. The client asks the authorization server to go and ask the resource owner for authorization in order to provide an extra buffer around the owner.

On the other hand, the OpenID Connect protocol considers the perspective of the client. The trouble is that the OAuth 2.0 protocol doesn’t have an explicit way of verifying who is giving authorization. You don’t know if it was actually grandma giving the okay to use her account to purchase the game unless you do some verification. Just like Little Red Riding Hood should do some verification to see if what’s lying in grandma’s bed is actually grandma, the client should verify that the authorization was provided by the actual resource owner.

Back to our story. In the preferred OAuth 2.0 method, we’ll ask grandma’s assistant to get grandma’s authorization to purchase the game on her account. Whether we go with the preferred method of asking the assistant to ask grandma or asking grandma directly, we want to verify that it was actually grandma giving the approval. Maybe it was grandma’s sister pretending to be grandma on the phone who gave the approval, so her sister could get the game for herself using grandma’s account. Or, maybe it’s a wolf wearing grandma’s clothes and lying in grandma’s bed giving the okay to purchase the game.

If the impostor is able to fool either the assistant or you into thinking she was grandma, we’ll end up heading to the store with grandma’s sister’s authorization, or the wolf’s, and not grandma’s authorization. We need to verify it was grandma and not grandma’s sister, a wolf or anyone else.

OpenID Connect offers protection to the client by including an authentication request with the OAuth 2.0 authorization request. So the resource owner, or impostor, not only has to authorize the access but verify they are who they say they are. Without the authentication request, we might mistakenly give someone else access to a protected resource just because they have a sticky note or receipt that they stole.

In other words, when we ask for grandma to authorize our use of her account to buy the game, we also ask for some verification of identity, so that we can be confident that it was grandma that actually gave the authorization (or denied it). OpenID Connect sticks with the preferred flow of OAuth 2.0 by having the client ask the authorization server to ask the resource owner for authorization so we won’t ask grandma directly.

In asking the authorization server to ask the client for authorization and authentication, we also allow the authorization server, called the “OpenID Provider” in the spec, to handle the verification of identity. Remember that the authorization server is meant to be a mutually trusted third party, so this doesn’t add any risk to the client or resource owner. Now, we’ve added protection to the client without compromising on the protection of the owners.

Using OpenID Connect, simply by submitting an authentication request along with our authorization request in the proper format, we can update the flow image we used in the OAuth blog:

With the addition of the OpenID Connect protocol, we can ensure both that the client gets authorization to the protected resource, and we verify who the subject giving authorization is (in order to ensure it’s the right person). OpenID Connect enhances our security, and it also gives us the benefit of having some information about the user or resource owner.

OAuth 2.0 and OpenID Connect protocols are just some of the best practices and steps to ensure reliable security. PingOne for Customers incorporates these and many more while delivering an easy and seamless experience for both the developer working with it and the customer using it.

To learn more, check out these videos of OpenID Connect and OAuth 2.0 flows or check out my original blog post on OAuth2.0.

Sign up for a Free Trial Today