Authentication vs Authorization

[00:00:00]
>> Kyle Cook: Now we do have to talk about a little bit of an elephant in the room, the difference between authentication and authorization, because most people just use the word auth, which stands for both authentication and authorization, but they're actually two entirely separate things, and in this workshop we are only going to be focusing on authorization. Anything related to authentication, we're not going to be touching at all.

[00:00:19]
Now the difference between the two is authentication is all about who are you. This is your typical login, whether you're logging in with email password, logging in with Google through like OAuth, it doesn't matter, it's just your way of authenticating who you are. This could even be like an API key that you send across to an API. You're just telling the server, this is who I am. So I log in with my email password, they now know that this is Kyle.

[00:00:41]
Authorization is essentially taking those credentials that you have passed along, they know you are Kyle, and now they're asking, what can you actually do? Do you have permission to delete this document? Do you have permission to edit this document? Can you create this thing? Can you view this thing? So everything we're going to be messing with is in this authorization camp, and essentially it's synonymous with permissions.

[00:00:59]
So we're going to be focusing on the permissions aspect of auth in general. Yes, Duster. And if people want to dive into authentication, Max Furtman has a web authentication APIs course that covers basically every way you can authenticate a client site app on the web. So yes, I would highly recommend checking that out because yeah, learning authentication is a tricky topic, so having someone to walk you through that is great.

[00:01:22]
Now the main reason we're going to be focusing so heavily on authorization is because authentication is one of those things, in most applications, you set it up one time, you create your email password, you create your OAuth, whatever it is, and you probably don't really touch it much throughout the whole lifetime of your application. Maybe you add a few more OAuth providers, maybe you add in passkeys or something else, but for the most part, your authentication code is kind of its own little bubble that you don't really mess with much.

[00:01:47]
But authorization on the other hand, is deeply tied to every aspect of your code. It doesn't matter if you have business logic, that's going to be touching your authorization. All your API routes, your database queries, your actual UI, every single bit of your code is touching authorization, so it pretty much touches your entire codebase, and if you write a bad authorization system, essentially your entire codebase is going to be full of bad code that's difficult to work with.

[00:02:11]
Also, unlike authentication, authorization is constantly changing. You have new permissions being added, every time you create a new feature, you most likely need new permissions to handle who can read this data, who can update this data, and so on. So it's something that's not only in your entire codebase, but it also constantly changes, so we need to make sure that it's easy to use and easy to update, which is one of the hardest things to do in programming is to make something easy to use and easy to refactor.

[00:02:34]
Now, obviously you're probably aware of this already, but if you get authorization wrong, you have tons of problems. If you permit people to do too much, you're overpermissive. Well then you have people accessing data they shouldn't, which is obviously a huge problem. But even on the other end, if you are overly restrictive and you prevent people from doing certain things that they are supposed to, you get frustrated users.

[00:02:53]
They get errors when they try to do something that they know they used to be able to do. This is something that's not good at all. And also, if you have inconsistent authorization, for example, your UI shows a button for deleting a to do, and then on the back end it prevents you from doing that, that means you have inconsistent permissions one way or the other. Obviously, it's worse if your permissions are wrong on the server, but you don't want them to be wrong in either place.

[00:03:15]
And of course, if you write a bad permission system, since it touches all of your code, it makes maintaining that code much more difficult. Now, this section right here has all of the goals of what a good permission system should have, and this is kind of going to be what we're trying to work towards in our permission system. So the very first thing is that it should be impossible to access any unauthorized data.

[00:03:33]
This is pretty self-explanatory. Your permission system, you want it to work. That's essentially what this section says right here. I want my permission system to work every single time. There should be no pages or access that people should get to, that they shouldn't have access to. Also, there should be a single source of truth. This is something that I actually find is a big problem in a lot of permission systems, especially if you're just putting if checks everywhere, is that now to figure out if someone has permission to do something, you have to check 7 different files that all write that code in a slightly different way.

[00:04:03]
So having one file or one set of files that contains all your permission logic is really important. This next step is one that a lot of permission systems also fail at, and that is automatic enforcement. As you're writing code, especially on a larger, more enterprise scale codebase, it's very easy to accidentally forget to add permission checks somewhere. And if you don't make it so that your code automatically enforces permissions for you, it's easy for a developer of any skill level to add a new feature and just forget to put those permission checks in.

[00:04:28]
Or they may think that those permission checks are already in place because they may think the code they're calling is authorized already, but it may not be. So you want to make sure it's impossible to access data unless it's already gone through authorization to make sure they have permission to access that. These next ones are a little bit more self-explanatory. Consistency between the front-end and back end, I already talked about that a little bit.

[00:04:48]
If your front-end shows that you can do something, the back end should allow you to do that, and if the front-end says you can't do something, the back end should prevent you from doing that. Having that inconsistency is just a bad user experience in general and can lead to security problems. Also, everybody already knows this, but never trust the client. If we're getting any data from the client, whether it's a URL or form data, doesn't matter what it is, we want to make sure all of that goes through our authorization system to make sure that we are only allowing things that they have access to.

[00:05:15]
And finally, this one is usually already met in most systems, but you want to fail closed. Essentially what that means is that if we have an authorization system and for some reason something goes down, like our database goes down or maybe some other service goes down, we want to make sure we automatically by default deny the user access instead of allowing them access, because if we allow them access by default, as soon as something goes down on our system, now everyone has access to everything, which is obviously not an ideal system.