In this article, you will learn about OpenID Connect by analogy, and how it relates to OAuth2.
In my last article, I described the benefits of living in the OAuth2 apartment building. Something I didn’t mention is that the neighborhood my building is in is really unique, too. There are several other buildings like mine (OAuth2-enabled) in the area, which has turned out to be very convenient for the local businesses and for the residents. I’ll give you an example of how this arrangement has benefited us all.
I was walking through the lobby recently and saw another advertisement on the community bulletin board, this time for “Ripley’s Gym”. They were offering a special discount for all new members, exclusively for people who live in one of the OAuth2-style apartments.
I knew that it was long past time to start exercising regularly, so I decided to call them up. This gym was very eager to sign up new members; competition is quite stiff for these sorts of businesses. To make it as easy as possible to get me started, they were willing to send Ripley himself over to meet me in the building lobby only a few minutes after I called.
Ripley had previously made a partnership agreement with the management of each of the neighborhood buildings. This partnership meant that there was a smooth process available for him to get the necessary details about each tenant when they signed up. It also meant that he knew that the people signing up were actually tenants in the building.
When he showed up to meet me, I saw the process first hand. First, I met Amy (remember her from my other article?) at the front desk, along with Ripley. I showed Amy my driver’s license, and Ripley showed her his business card. Amy then had me sign a quick release form which stated that I was okay with Ripley having some of my personal information: name, age, gender, mailing address, phone number, and email address. Given that this meant I didn’t have to fill out a tedious membership form, I was happy to sign Amy’s release form.
Amy then printed out a small ticket for Ripley with had all of my personal information on it. One really cool thing about this ticket is that Ripley was able to instantly scan it and use the information within to register me at the gym. This was possible because the information on the ticket was standardized; every single OAuth2-style apartment building in the neighborhood has the ability to print these same types of tickets with the same standard details about the tenant. Each ticket is also watermarked with the building address that it came from, which means that only legitimate tickets will be recognized.
Now that I was registered with Ripley’s Gym, there was another neat option available to me as a tenant from one of these buildings. Every time I wanted to go to the gym, I just needed to grab a ticket from the apartment front desk on my way out the door (they can print these very quickly). I can use this ticket when I get to the gym as a form of identification, and also as a simple way to keep my customer information current within the gym’s files. You see, if my phone number or email address (or anything else about me) changes over the course of my time as a gym customer, I won’t have to remember to keep them updated. These details are stored on the tickets, so every time I visit the gym, they have my most current information.
Nothing about this ticket-issuing process is unique to Ripley’s Gym. Any of the local businesses that are willing to follow this process are welcome to do so, and many of them do. Likewise, when a new building is opened, the details about how businesses can start serving its tenants are published in the lobby. These details always follow a well-known template, making it very easy for businesses to serve those tenants.
Working with the local businesses like this has become a way of life for the people in our neighborhood, which has made things easier for everyone. We no longer have to deal with repeatedly filling out customer sign-up forms or updating our personal information, and we no longer need to worry about carrying keys for each of the members-only services we want to use. Instead, we just get a quick ticket from the front desk and we are on our way. Honestly, I tend to avoid businesses that don’t follow this process; it’s just not worth the hassle.
You might notice there is some similarity between the experience I described with “Clint’s Dog-Walking Service” and “Ripley’s Gym”. In both cases, I met the owner at the front desk with Amy, and in both cases, I signed a form granting my consent for Amy to offer something to the business owner on my behalf. In Clint’s case, he got a key card that gave him the ability to open some of my apartment doors, and in Ripley’s case, he got a ticket that had some of my personal information on it. The difference between key cards and tickets may sound obvious, but it is worth highlighting them:
- Information stored within the key card is hidden from the person receiving it; and information stored within the ticket is intended to be read by the person receiving it.
- The key card can be used to open apartment doors; but the ticket does not imply any such authorization.
- The ticket can be used as a standard and secure means of identification; using a key card as a means of proving your identity would be awkward, imprecise, and would vary from building to building.
Despite these different uses, it is quite convenient to have a similar process for both. Amy does a great job of facilitating these interactions; she has all of the tenant information, consent forms, ticket printers, and key card machines necessary to make everything work quickly and easily. Also, in more and more cases, businesses want a ticket and a key card at the same time, since this makes it easier for them to keep track of whose key card belongs to whom. Given that, having Amy handle it all only makes sense.
No surprises here: this isn’t really my neighborhood. It’s OpenID Connect. This analogy explains why OpenID Connect was created and how it relates to OAuth2.
As you can tell from the analogy, OpenID Connect (OIDC) is designed to solve a very different problem than OAuth2. OIDC is designed to help identify people consistently, regardless of the “identity provider” being used. OAuth2 is designed to request limited access to people’s resources, and is highly specific to the resources in question. As I mentioned above, although these uses are different, they are often complementary.
In my analogy, Ripley’s Gym is known as a “relying party.” A relying party is any entity that uses (or “relies” on) an external identity provider to establish the identity of its users.
Each of the “OAuth2-style apartment buildings” is an example of an identity provider. The main thing that a relying party needs from an identity provider is an “id token“. These are the “tickets” that I described; they are in a standard format (known as a JWT) that contain various details about the user, and are cryptographically signed by the provider (conceptually, this is similar to a watermark). These id tokens are suitable for registering users (as Ripley did when I first signed up for the gym), as well as logging users in (as I described using them to get inside the gym).
Given that one of the main points of OIDC is interoperability between providers, all OIDC identity providers are required to publish a “discovery document” which tells the relying parties exactly how to work with it. This is that “well-known” template I mentioned that the neighborhood apartment buildings had to have available. The discovery document includes details like where to go in order to authorize users, where to get tokens, where to get information about users, …
You can use ForgeRock Access Management to implement the role of an OIDC Identity Provider. There are many libraries certified by the OpenID Foundation which can help you build a relying party. If your relying party software can’t be made to work as a relying party directly, you should also consider using the filter provided by ForgeRock Identity Gateway to build this feature.
By building your software services using this pattern, you will foster a convenient and secure environment for your users and your business partners. Go forth and be part of the OpenID Connect neighborhood!
#OAuth2andOpenIDConnect
#Authentication
#JWT