Basic Understanding of OAuth2.0 and OIDC
In this article I’ll be explaining what OAuth2.0 and OIDC are. I’ll use a different analogy than the one you may be familiar with, introduced by Aaron Parecki in one of his talks. It’s a good analogy and explains OAuth2.0 really well, but it also explains it in a way that some people might misunderstand how it works. It also doesn’t get into OIDC, which is built on top of OAuth2.0 and often are implemented together.
The Hotel analogy
This analogy uses a hotel and it’s front desk, a hotel key card and a hotel room. The front desk serves as a figurative representation of the authorization server, the hotel key card represents an access token, and the hotel room is your resources that you can access with your key card.
The danger is still there as anyone with your key card can access your resources, and the expiration of the card is comparable to the lifetime of the access token.
The problem lies in a known problem, and that is who can get your hotel card and use it. In real life, it’s not you who are getting your access token and it’s not you who requests it either. Instead it’s the client you are using that requests the access token on your behalf. And here comes an alternative analogy, that hopefully can help you remember how OAuth2.0 works.
The alternative analogy
Imagine you have a vault in a secure bank with a ton valuable old LEGO® sets, like the Galaxy Explorer from 1970 or the Space shuttle from 1996. Unfortunately the bank holding your LEGO sets has gone bankrupt and you decide to move them to a new bank. Because the LEGO sets are very valuable, you decide to get a courier specialized in moving valuable objects, to move your LEGO sets to the new bank.
A keycard is needed to get into the vault. It only works for a limited time and is given on arrival. The keycard can only be issued after a keyword has been provided.
When the courier arrives at the bank, the banker needs to make sure that the courier is actually allowed to obtain a keycard and therefore decides to give you a call. You of course need to verify that it is you, who gives the acceptance. You tell him the keyword and the banker then issues the keycard to the courier.
Now let me explain what the different things represent in OIDC and OAuth2.0.
Understanding the underlying flow of authentication and authorization
The following diagram shows a simple overview of how authorization and authentication look like. The important part to notice here is that the authentication isn’t happening on the app, but instead on the OAuth2.0/OIDC server.
This diagram should help you visualize some of the concepts that will be presented in the next sections.
Authentication
Let’s start with the easy one — OIDC. It’s the protocol that’s built on top of OAuth2.0 and lets you authenticate identities by different means, and also provides another token besides the access token from OAuth2.0, the ID token.
I won’t go into too much detail about the ID token, besides that it contains information about you, like date of birth or nickname.
The keyword represents your password in authentication. It’s something that proves you are, who you say you are. The important part here is, that you trust the bank to not let the courier know your keyword.
Authorization
Now we come to the hard part and where the hotel analogy hits the fan. OAuth2.0 is a protocol for authorization that helps apps or clients gain access to resources. Like mentioned before, this is where people can get confused in the hotel analogy — the access token gained from the authorization request is compared to the keycard you get when checking-in, which lets you enter your room. It also gives other people access to your room, should they be in possession of your keycard. And that part is sort of true. The problem here is that in OAuth2.0 it’s not you who request the hotel key card, neither is it you who enters your room. It’s the client that requests the access token and it’s the client that wants to access your resources.
In the alternative analogy the bank represents the Authorization server, the keycard represents the access token, the vault is the resource server, your LEGO sets are your resources and the courier represents the client. When the banker calls you to verify it’s really you, you are also giving consent to let the courier go into your vault. A last point to note is that the bank doesn’t know whether someone steals the keycard from the courier, meaning that anyone with the keycard can gain access to your vault, and that is why it’s so important to keep it safe.
I hope this has given you a basic understanding of what OAuth2.0 and OIDC is, and it helps remove any misunderstandings you may have around who and what the OAuth2.0 works on.
