Today, we’re talking about JSON Web Tokens. Why? Because user authentication is important to any piece of software, and my boss wouldn’t let me write a blog about J’son Spartax (the TRUE father of Guardians of the Galaxy’s Starlord). By the way, JSON is an acronym. It stands for JavaScript-Object-Notation. Man, we developers love acronyms and abbreviations. (Yes, there’s a difference. Google it.)

So what is a Json Web Token, or “JWT”? That part is easy. It’s an alternative way to achieve user authentication for an application that doesn’t have access to a database. This may be a little confusing if you’re not in the world of development. So rather than telling you the textbook definition, let’s dive into the problem that JWT’s attempt to solve.

Almost every time you use a piece of software, be it a web application or a piece of software that exists on your desktop or phone, you usually have to log in to do anything that actually matters. Each time you go to do a thing, the software will want to make sure you’re allowed to do whatever it is you’re trying to do. This is what we mean when we say “User Authentication”. It’s really not unlike going to a bar and having to show your driver’s license. This is how the company can be sure that you are who you say you are.

There are all kinds of different programs and websites, and they’re written in all kinds of different programming languages. To keep things simple, we’re going to approach this from a PHP (which ironically stands for Php-Hypertext-Preprocessor, not even kidding) point of view. Whenever you use something written in PHP, such as a website built with WordPress (responsible for a stupid amount of websites on the web today), your user validation information is stored in something called a “Super Global Variable” known as “Session”.

This isn’t the only way to do handle user authentication in PHP, but it is the simplest, and most popular way. Any “session” information is stored on the server, so it keeps people from accessing the data through your browser storage, like cookies.

Just in case you don’t know what cookies are, they’re basically the browser version of a server’s “session” concept. The issue here, however, is that they can be accessed by anyone with access to your computer. Anything stored in cookies may as well be considered open for public viewing. In general, it’s a bad idea to use cookies for user authentication. Or is it? Spoiler alert: not necessarily.

Whenever you go to do something, the software will check the information stored within your session variable to make sure that you are logged in and have the authorization to do different things. Usernames access privileges, and other non-sensitive (seriously, no passwords in here) data can be stored within sessions to be called from one page to another without having to re-submit things like you would with other methods. But what if you didn’t have access to this?

These days, RESTful applications are the bee’s knees. Everyone wants’em, and for good reason. But we’ll get into that another time, as well as what it means. For now, just know that we can’t use server information for a truly RESTful piece of software. But we still need a safe, secure, page-to-page way to handle user-specific information. And most of the time you use an application on your phone, that application has no knowledge of a database. It gets everything through an API that acts as a middleman between the server that holds the data, and the application being used by the client. This is where the web tokens come in. ANATOMY TIME!!!!

JWT’s will always look like this:

header.payload.signature

Well, kinda. You can actually read those words. An actual JWT will still be in that format but will look like a bunch of gibberish. The ‘header’ part just says what kind of algorithm to use, and what it is. The payload contains the actual data. Username, access privileges, and definitely-not-passwords. Seriously, that’s a terrible idea. Now, you’re gonna mask these to an extent. But it can easily be undone. With little effort and know-how, anyone can easily get the data out of the token. But that’s fine. We don’t care if they have your username. The only thing we care about is can they actually USE it. Nope. This is where the signature comes in.

The signature is a combination of the header and payload, which have already been masked, but then go through a “hash” process using a secret key that is stored on the server. This is where all the magic happens. Without that key, there’s no way anyone can actually do anything with the data. So sure, they can try and change the payload data and try to pretend to be another user. If they do this, however, the header and payload won’t match the hashed signature. Token gets destroyed, and now you have to sign in again. A minor inconvenience, sure. But the point here is that your data can’t be accessed by someone pretending to be you. Oh, remember the cookie thing? It’s completely safe to store web tokens inside a cookie. Since the information being stored there isn’t sensitive, there’s no need to fear that information being accessed or altered.

JWT’s are great, but they aren’t entirely without flaws. But to be fair, no method of user authentication is. But as long as you use them correctly, and make sure you use additional security measures like token expiration dates, and most importantly making sure you’re using SSL certificates on both ends of your web application, you’ll be hard-pressed to ever run into these issues.