DEV Community: Sam Huckaby

Understanding OAuth - Terminology

Sam Huckaby — Mon, 06 Nov 2023 03:04:31 +0000

In my last post, we walked through some real-world systems that map roughly to the OAuth framework. In this article, we will discuss the key terms that go along with the framework.

I’ll be honest with you, I love big words, but I can’t always remember big words. So in this post, we’ll look at the big words that OAuth uses most frequently and try to break each one down into smaller, more memorable pieces.
To start, we have the Resource Owner, which is often thought of as just “the user”, but is actually the person or machine who should be able to access… something
That “something” is a Protected Resource, which is just a fancy way to refer to that thing-i-only-want-certain-people-to-touch. To put it in context, this might be the photo album in your social media account that you want to upload embarrassing karaoke pictures into.
This brings us to the Relying Party, which is NOT the most boring party ever, but is instead the party or application that must rely on another source for authentication. This might be the social media platform that needs some other source to confirm that the user is allowed to access those prized karaoke pictures.
That “other source” that the Relying Party uses to determine users’ authorization is called the Authorization Server. This term tends to get muddied the most, and can be called a range of things like “Authorization Provider” or “OIDC Provider”. I personally prefer the term “Authorization Provider” because this actor provides authorization as a service, and is not necessarily a free-standing “server”. The Authorization Provider will usually be a third party source like Google or Beyond Identity, that provides authentication as a service so that your users can log in.
Once the user is authenticated, the Relying Party is able to retrieve one or more Tokens which provide critical information. There are two key tokens that you need to be aware of, and those are the Access Token and the ID Token. The ID Token is optional and may be requested in various ways. It is intended specifically to be used by the client-facing portion of the Relying Party to identify aspects about the User. The Access Token is intended to be used by the server-facing side of the Relying Party, and should never be visible to the client. It is used to provide authenticated access to upstream servers or services - like that photo album service, so you can delete those karaoke pictures before it’s too late. Seriously. Go delete those pictures.

Understanding OAuth - Overview

Sam Huckaby — Mon, 06 Nov 2023 02:40:35 +0000

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.

What I like about Bytes

Sam Huckaby — Sat, 28 Jan 2023 23:19:48 +0000

It's been a wild ride since I discovered and first subscribed to the Bytes newsletter. It really has been my go-to place for information about what is happening across the JS-verse. In the most recent article it was noted that no one had written an article detailing what is so great about their newsletter and so I decided to fix this.

I have almost no experience with other technical newsletters, so there will be limited comparisons in this article. But let's be honest, if you're reading this, you don't really want a comparison, you just want to hear why I love Bytes, and maybe some jokes along the way.

I'd like to say I rewrote my entire newsletter to use Bytes, but frankly, that sentence makes no sense, and I don't write any newsletters. Instead, below are the reasons why Bytes is the only newsletter I subscribe to and why I think you should too.

Bytes provides actually information

I don't subscribe to any other tech newsletter. Maybe you think this is crazy, but honestly, reading Twitter usually gives me a faster flow of information than a semi-regular email that I may or may not check. Bytes is the first and only tech newsletter that I've put in the effort to read regularly, and that is basically because it's comedy gold. When Astro.build hit my radar, it wasn't just because a couple people I follow on Twitter said it was cool (yes, that helped) but because I saw the words Astro.build in a Bytes newsletter and realized I hadn't played with a new library or framework lately and clicked the link. It's not important that I still haven't built anything with Astro (I definitely will) but rather that Bytes was the catalyst that convinced me to say I would try it.

Bytes gives me a reason to get up in the morning read it

Bytes has provided me with content that I love, sarcasm that hurts me (in a good way), programming puzzles that I actually attempt to solve, and a pulse on frameworks that I am actually interested in. While I'm not looking for a job, I still carefully peruse the job listings in each edition so I can a) mock the ones I think are silly and b) mercilessly bombard my friend with links to apply because their job "isn't cool enough, and you should try something new". Sometimes Bytes even includes Twitter content, so that's one less thread I will need to read and like all the replies on.

Bytes doesn't waste time with non-JS stuff

We get it, Rust is awesome, type-safe, and blazingly fast. I'm just not smart enough to learn how to use it. It's always painful to watch two genius-level developers show me how easy it is to write Rust in a YouTube video I can't ignore. Bytes on the other hand understands that I am a lowly front-end developer who loves JS and has been writing it for more than two decades. I get it, I could setup an API with Scala or Go much faster, but I understand Node.js. I use NextJS because it's a framework I wish I had built myself, even if the API setup can be confusing sometimes. Bytes doesn't try to convince me I'm wrong for loving JavaScript, it sits down next to me, nods in agreement, and then helps me find a new helper library to fix something underscore solved a long time ago.

Summary

Maybe you finished this article and you thought, "wait, do you actually think I SHOULD read Bytes?" and the answer is yes. If you want content that is actually interesting, gives you non-farming takes on web tech, and understands that you love JS even if there are other options out there, then you want to read Bytes. It's basically the wordle that you only have to remember once a week and you always win in under four guesses. Take the W and go subscribe to Bytes for a way better read than this article was.