If you are reading this article, it's very likely that you have found yourself needing to understand the workings of OAuth. This is in some ways a very commendable task, because OAuth is one of the most used and important authorization frameworks used across the internet.
OAuth is in some ways quite simple and in other ways quite complex, but I will attempt to dispel at least some of the mysticism surrounding it. To do this, we will take a look at how OAuth corresponds to some real-world systems.
OAuth is the “authorization framework” used across the web. The technical name can make it seem somewhat mysterious, but in reality, it describes a pattern (a.k.a. framework) of access that is common even outside the realm of computers. The problem that OAuth is trying to solve is secure authentication by a third party, or you might say, allowing someone I trust to determine if my users are who they say they are. This is important because not every entity is built with authentication in mind, but almost every entity requires some level of authentication. Some examples might be a valet who needs to be sure they give keys to the right people, or a doctor who wants to be sure she has the right person’s medical history up when prescribing medication..
Let’s take a look at a real-world example to see how this pattern plays out. Imagine you’re getting ready to fly to your next vacation destination, somewhere beautiful, like Michigan. You’re going to purchase a ticket from an airline (the relying party or client) and provide some identifying information about yourself. The airline has no way of knowing if the information you have provided is real, because they are not built to handle identifying every person on earth, so they rely on an authorization provider which in this case is the government which issued your passport. Now, when the time comes for you to head to beautiful Michigan, you arrive at the airport and in order to sit in your seat on the plane (the protected resource) you are redirected by the airport to a security checkpoint first that allows your identity to be confirmed by agents of your authorization provider. You give them your boarding pass (which is sort of like an authorization code) and your passport and then you are granted access to the plane, assuming you didn’t steal someone’s identity.
In a nutshell, this is how OAuth works too. A user (resource owner) interacting with a client (relying party) is referred to a (possibly) third party authorization provider that validates the user and then returns an authorization code which the client can exchange for a token (or tokens) that grants them access to a protected resource.
Check out the next post for a detailed walkthrough of the terminology used above.
Top comments (0)