What is JWT (JSON Web Token)?
What is JWT (JSON Web Token)?
JSON Web Tokens (JWTs) is an open standard (RFC 7519) that defines a compact and effective way to send information, usually between a client and server. It is commonly used in scenarios with OAuth and OpenID Connect protocols where JWT is considered a good option for access tokens since they can be signed or encrypted. In this article, we’ll explain how JWTs are structured and why and when you should use them.
JWTs for authentication, and other things
JSON Web Token (JWT), pronounced “jot”, is a compact and lightweight way of sending information. JWTs are primarily used for authentication, but they are technically just tokens that contain base64 encoded JSON, allowing it to be used in many different ways. However, in this article, we’ll focus on JWTs’ use for authentication and authorization since that’s where our expertise lies.
One of the reasons why JWTs work well for authentication is that they are self-contained and can be signed or encrypted. Being self-contained means that all information necessary for authentication and authorization is contained in the token itself, reducing the need for additional database queries. JWTs contain JSON objects which can store information that we want to send in a safe and protected way. By signing (hashing) or encrypting our JWT, we can ensure that the client or a malicious party hasn’t altered the content.
Why use a Token-Based Authentication method?
Let’s imagine a digital service that provides music streaming for its users. To access the music, a user must have a subscription, and to validate that a user has an active subscription, the user must sign in to the service. When signing in successfully, we want to keep track of the user and ensure that every call their session makes to the server is validated.
The server could store session information (session-based authentication) and let the user call the server by providing a unique session ID. But that can quickly cause scalability issues when the server has to look up the session ID that the user sends.
Instead, we can utilize JWTs, where the server sends a token (JWT) to the user after authentication and authorization are done. Since the JWTs are compact and self-contained, we can send the JWT (which the server provided) with every new request. This reduces the number of database queries and enables a more scalable authentication method for users.
JWT structure
A JWT contains three parts: Header, Payload and Signature.
-
Header
JWTs header contains parameters for which hashing algorithm is being used to generate the signature (e.g. “HS256” or “RS256”) and the type of the JWT.
The JWT standard requires implementations to support at least HMAC SHA256 (“HS256”). Additional cryptographic algorithms are introduced with JWA (JSON Web Algorithms, RFC 7518). -
Payload
The payload, or body, contains the data and information that we want the JWT to transport, usually a set of claims that provide the server with information about the users’ data, roles and other authentication information. JWTs have seven Registered Claim Names as standard, but we can also include custom claims, depending on our goal.
In our example, we’ve used the Registered Claim Name Issued At (“iat”) and Expiration Time (“exp”) as well as our own custom claim “role” that provides the role of the user. -
Signature
A string that is generated by the cryptographic algorithm (that we specified in the Header). This string is used as a signature to securely validate the tokens’ integrity. It’s a critical part of the JWT and should be the first step that any JWT consumer takes. If the signature doesn’t match the server’s expectations, the JWT could have been tampered with and should not be processed.
Why should I use JWTs?
I want to preface this section by saying that JWTs aren’t the solution to every existing authentication challenge. Depending on your solution and goal, JWTs might even hold you back. But going into the options for JWTs and their pros and cons is another article we’ll get to in the future. Today, let’s focus on why you should use JWTs for authentication:
-
Secure
JWTs can be encrypted and/or signed to safeguard them from being modified by a malicious party. They can use symmetric signing, meaning that a shared secret key is used to sign and verify the token (“HS256”). JWTs can also use asymmetric signing, using a public/private key pair to sign and verify its integrity (“RS256”). In this case, the server signs the JWT with a private key, and the client verifies it with the public key. This ensures that only the holder of the private key (the issuer) could have created the JWT, increasing security and minimizing the attack surface. Authway (and other IDPs) use asymmetric signing for the highest protection.
-
Compact
JWTs are a single, self-contained string that encapsulates all necessary information in a single token. Together with Base64URL encoding, this makes it easy for JWTs to send in URLs, HTTP headers, or even cookies. JSON-based JWTs are also smaller than XML-based tokens (like SAML, which uses XML), which are larger due to their XML tags and formatting.
-
Common
JWTs are common in OAuth and OpenID Connect applications, they are widely used for Single-sign-on (SSO) and since it’s essentially just JSON there are many JSON parsers that can be used with almost any programming language. JWTs being common and easy to work with is why they have grown very popular.
-
Efficient
You can verify a JWT quickly since it doesn’t require a database query. When handling hundreds of thousands of users, performance is a key factor to pay attention to. JWTs can alleviate some of the pressure on your database compared to session-based authentication. Since JSON is a common format, it’s also very easy and efficient to process on users’ devices, especially mobile.
When should I use JWTs?
Since JWTs are JSON-based, you can use them for whatever data or information you want to send securely between two parties. But most commonly, we talk about JWTs when discussing authentication and authorization.
-
Authentication
A user successfully signs in to your application using their credentials; the server then responds and issues a token. The user can then use this token when calling the server to show that they are authenticated and who they are. ID tokens can be any token, but the OpenID Connect protocol requires the ID token to be a JWT.
-
Authorization
At the same time, the server would also issue an Access token. The access token is used when the user makes requests to access data, routes or other resources. The ID token identifies the user, and the Access token specifies what access the user should have. The access token doesn’t have to be a JWT but could be to simplify development.
That’s our crash course in JWTs! This article covered JWTs, how they’re structured, and why and when you should use them. There’s a lot more to JWTs and ID/Access tokens in general, but if you’re curious to know more you can reach out to us, we’re happy to share our knowledge and expertise.
One thing to note is that while JWTs can be encrypted, most of the time, JWTs are only signed, meaning that anyone who gains access to your token can also see its contents. You should never send sensitive information through a JWT. But if you follow best practices and use established protocols like OAuth and OpenID Connect, you’ll have a robust way to authenticate and authorize users in your application.
Have questions about JWTs or how we use them here at Authway?