So you’re building an application and have just realized you want to allow your users to login. You’re not sure that you know how to handle this situation. But you’re worried that you’ll do something wrong. You’re worried that your users will be compromised.

Not to worry, you’re in good company. User session management is one of the most important but least understood factors in modern web applications. Some of the confusion comes from the terminologies we commonly use to describe it.

You’ve probably read about user authentication systems, access tokens, and OAuth. These things are only part of the picture and probably why you’re a bit confused. In this series I’ll explain the different concepts you’ll need to know and describe some of the common methods of implementing them. Along the way I’ll warn you of some of the common pitfalls and weaknesses of each of these options. Additionally I’ll give you a list of questions you can use to decide how to design your authentication and authorization system.

To start off, we should define some terms:

User—some potentially untrustworthy schlub.

Authentication—Determining who the user is.

Authorization—Determining what the user is allowed to do.

Token—a bit of data that I gave you that's hard to forge; only I know how to prove its validity.

Authentication vs Authorization

So you’ve been hearing about user authentication everywhere and you might be asking yourself “How is authorization different from authentication?” And “Why would I need authorization if I already authenticated the user?” These are good questions as it’s not often made clear that they are different concepts, but they intertwine quite a bit.

Authentication is your user proving that they are who they say they are.
Authorization is you deciding if they are allowed to do what they are asking to do.

Let’s look at a real world example of these two concepts:

The Seal Club

Imagine that you’re opening a very exclusive, private night club. You’ve hired a manager, a bartender, and a couple of bouncers. Only members can get into the club, but these new bouncers aren’t going to know your regulars yet. So they’re going to authenticate your potential guests by asking for a picture ID to prove who they are. The bouncer will compare the photo on the ID to the person in front of them and decide if they’re really the person on the ID. Your bouncer authenticates that the person who is who they say they are.

You're a bit worried about the bouncer having the member list, he'll be out on the street and anyone could steal it. So you've told him to radio the manager to find out if they are a member. If the manager says they’re a member, then he can let them in. The manager has authorized the member to come inside.

This is the most basic form of authentication and authorization you will run into in the real world. The user proves they are who they say they are and you decide if they can get in and do whatever they want.

Some time later...

Your doors have been open for a few weeks now and you’ve had a rash of members running up huge bar tabs and not paying. To combat this you’ve told your manager that you don’t want people being served unless they’re not on the list of deadbeat members. The manager goes to the bartender and says “I need you to check with me if someone wants to buy a drink.” The next time a member goes to buy a drink the bartender checks with the manager who says “Well who is it?” So your bartender asks the member for their name, (authenticating them), and tells the manager who says “Oh, that’s old Mr. Won’t Pay His Bar Tab. Don’t serve him.” A few minutes later another member comes up and the process repeats but this time the manager says “She’s cool. Go ahead.” This is an example of an authorization check. You’ll notice a little bit of authentication too. Since the bartender has to find out who the member is to find out if they’re authorized to buy drinks.

Things can always get better

So things have been going well with your club for a few months now, but your regulars are getting tired of having to show ID every time they come to the club. So you buy some fancy RFID bracelets and tell your bouncer to put one on any member who shows their ID and is on the list then scan it and mark who it is in the rfid system. Then when someone has one of those bracelets to just let them in.

These bracelets are an example of a token. They say, I already agreed that you are who you say you are and that you’re allowed to come in.

An unintended benefit came out of you passing out the bracelets to your members: your bartender can now scan the bracelet and the system can automatically tell him if the member can buy drinks or not. This saves him and your manager a ton of time. Huzzah! Happier staff and happier members!

Bringing it back to code.

To bring that back into the world of web applications: the different people in this club are different subsystems of your application. The bouncer would be a login system, the bartender would be some API that only authorized users can access, and the manager would be your authorization system. The bracelet would be the equivalent of an access token.

Same Bat Time, Same Bat Channel

In the next installment, I’ll explain some common implementations of authentication in the web application world, some common pitfalls when implementing each of them, and some of the common attacks that can compromise them.

Until then dear reader!

Web Authentication For Actual Humans:

1. This Post
2. Part Two
3. Coming Soon