Introduction to OAuth2

Mar 26, 2019 06:31 · 516 words · 3 minute read Tools Authorization OAuth2

QUICK! NO TIME FOR HUMOR, GET INTO THE CAR!

You get into the car against your best judgement, wondering what in the holy hell this is about. The car tears down the street that is empty from all human life, to your great surprise.

We need to get you up to speed fast. Back in 2012, a bunch of apparently very clever chaps came up with a second version of OAuth that was not backward compatible. It got pushed by all the big players as the recommended (or only way in some cases) way to talk to their API.

You’re afraid the stranger who’s driving will blame it all on –

It’s all very complicated but 15 years from now, civilization goes to hell and it’s all because of OAuth2.

… Yup. He went there.

So, I need you to stop OAuth2, but in order to do that, you need to understand it, so I’m going to explain it to you as we’re gunning down the highway at 150 mph. Good? Good. Let’s start with an overview. First up, let’s talk about the actors in this thing. Then, we’ll talk about so-called flows (their real name is “authorization grants”).

Roles

We have a few different roles voiced out in OAuth2:

  • Resource Owner
  • Client
  • Resource Server
  • Authorization Server

Resource Owner

That piece is your end user, the person using the app.

Client

That is your app, itself. It talks to resource servers on behalf. What is a resource server, you might ask?

Resource Server

… is the thing that protects access to resources for the user. This is the service your client wants to talk to. This is the Google service, the Facebook endpoint, and it only gives access in the hopefully correct amount to the hopefully correct client by virtue of the…

Authorization Server

… which is responsible for making sure that the user is who he says he is, that the client is what it says it is, and to confirm with the user exactly what is THE SCOPE of the access it should grant to the client. See what I did there? You’ll thank me later.

Grant Types

People like to call these “flows”. They come in four (4) flavors. They all have a purpose that is very specific.

  • Client credentials
  • Authorization code
  • Implicit
  • Resource owner password credentials

I’m not going to get into the specifics of what each grant type does, but these are essentially four different ways to get access to the Resource Server’s resources.

This is supremely important: All but the client credentials flow are about access to end-user (that is, Resource Owner) resources. The client credentials grant type is specifically for client-owned resources, or pre-arranged exceptions with the Resource Server.

A Protocol for Auth

Essentially, the above definitions allow us to define an authorization protocol for the interaction between a client and a given resource. We’ll get into the specifics of that in the next episode.

Puzzled, you look at the stranger driving the car.

Did I do away with the fourth wall again? Crap. I gotta stop doing that.