If you work with any kind of tech, chances are that you’ve heard of (and used) JSON web tokens. While using JSON web tokens is now almost ubiquitous with machine-to-machine (M2M) communications, it can be easy to take them for granted.
But that doesn’t make them any less critical to keeping modern business functions going. With JSON web tokens ruling the way we create, manage, and share information, it’s more critical than ever for us to understand what they are, how they work, and how they’re used.
In this 101, we’ll dive into the basic facts, functions, and need-to-knows of JSON web tokens. Get to know what JSON web tokens do, why and how they are made, and how these basics apply to real-life everyday work.
What Are JSON Web Tokens?
Let’s start with an easy question that might have a pretty complicated answer: What are JSON web tokens?
Simply put, a JSON web token (or JWT – pronounced “jot”) is an open standard for securely sending data as a JSON object.
What does that mean in regular English? It’s a method of transferring data from one place to the next in JSON, or Javascript Object Notation. What is JavaScript Object Notation? It’s a common way of formatting data.
The great thing about JSON is that it’s structured using key-value pairs, which makes it easy for people to read and understand. That also makes any human intervention a lot less prone to inducing giant headaches.
JSON web tokens are the MVPs of API calls. They’re a type of API secret commonly used to authorize entities (including human and machine identities) to access services, data, and resources that are permitted. That means a JSON web token contains information like an identity and expiration date that’s applicable across an entire ecosystem. Keep in mind this is different from an API key that provides application-level security, meaning it gives all users the same type of access.
So what does a JWT actually look like? Here’s a basic breakdown of its structure:
- Header: This first section typically identifies the type of JWT and signing algorithm.
- Payload: The next section contains the JWT’s claims – or information about the entity requesting API access. We’ll get into what exactly “claims” are in a minute.
- Signature: This last section is created by a secret (e.g., private key) that verifies the JWT’s sender.
Wait, JWTs Have Claims? Like, Car Insurance?
Not exactly, so don’t expect to get any money back from Allstate anytime soon.
As we mentioned before, JWTs send “claims” in JSON. Those claims contain data that is usually asking the recipient API to do something – whether that’s creating, destroying, or updating new data.
How do those claims work in practice? Imagine you’re a developer working for a bus ticketing company. Chances are you have a lot of data on buses, destinations, and drivers. Your company has just added two new bus models to its roster, so it’s time to make an update. That means you need to make an API call to your database of buses in network. To ensure that you, the authorized user, are making the update, you might need a JWT to grant access.
That JWT would have a “claim” in it detailing your level of authority, your particular user login, and what you want to do in the bus database.
How Do JSON Web Tokens Work?
To really get into how JWTs, let’s first dive into their origin. The first draft of JWT was developed in 2012 by the IETF Trust. JWTs were developed as a method of data exchange and a way to exchange claims between two users in an organized, simplified, and standardized format.
JWTs are most commonly used as bearer tokens. This means that receiving entities accept those tokens from whomever (or whatever) sent them. They’re now often a part of modern security standards, with OAuth (an authorization standard) often processing JWTs as access tokens and refresh tokens.
As stated, JWTs contain a set of claims to be transferred from one place to another. These claims are usually requests from the original sender to the receiver for some type of access. Claims requesting access can be very detailed and usually reference specific durations and scope of access granted by the recipient machine.
Once these tokens are processed, requesting users can use them to make all kinds of API calls until the end of their session.
So Why Do We Use Them? Can’t I Just Use A Password?
We use JSON web tokens because they’re an easier, simpler way to validate identities and grant appropriate access. JWTs contain all the information about an entity attempting to use an API. They help authenticate potential users and identify what level of access the user should have.
JSON web tokens are also super compact and relatively easy to wield. Since the output of JWTs is a Base64-URL string, that means it can be easily passed in HTML and HTTP environments. That’s a huge reason why they’ve become so popular as an authorization tool.
They’re also URL-encoding safe. That means if any data or call gets URL encoded (aka, turned into special or invalid characters to mask the real, sensitive data), the JWT will not be destroyed. In a world dominated by M2M communications, that’s a giant plus, as streamlined processes are an absolute must.
JWTs eliminate the need for redundantly querying databases and authorization servers. These tokens work like a “one-and-done” type of authentication. If a user has the right JWT in their hands, then they’re good to go. No need to keep logging in or manually proving identity with every API call. That saves businesses a whole lot of time (and therefore, money).
Putting JSON Web Tokens Into Practice
We can talk about JSON web tokens all day, seriously. But sometimes, it’s best to walk through things to understand them. Here, we’ll focus on how JSON web tokens work in practice.
Here’s an example of how JSON web tokens would be used to access a RESTful API:
- First, we’ll start with a user. This can be a human or a machine. When they want to access an API, they’ll usually send in a sign-in request. This request typically contains some type of username, password, or other kinds of sign-in credentials.
- Next, credentials are then sent to the API. Once those credentials are verified by the API, it will create a JSON web token to be sent back to the requesting user.
- Then, the user will send the API request (e.g., the header) along with the JWT to the server.
- Finally, the server will verify the JWT and view the claims – either granting or denying the request.
And voila! Users no longer need to authenticate their identity with every API call – allowing a more streamlined, hands-off way of accessing and working with APIs. That opens up more efficient workflows and a clear pathway to faster production.
The Role of JSON Web Tokens in API Security
JWTs remain an essential part of the M2M communications that power modern businesses. They help expedite the workflows relying on APIs and boost API security by streamlining user authentication.
They’re a set of credentials that specify how long and what the requesting user will have access to. JWTs are verified with every API call to ensure that requests are coming from the same authorized user.
Think of JWTs as a daily private parking pass. You’ll have access to a certain spot on a certain level for a set amount of time – but once that session expires, you’ll be on the lookout for another pass the next time you want in.
CTA: JWTs fall under the realm of secrets. Learn about the current security status of API secrets in our 2023 Corsha State of API Secrets Management Report.
