New Story

JWT vs PASETO: What's the Best Tool for Generating Secure Tokens?

by Josson PaulJanuary 9th, 2025

Too Long; Didn't Read

JWT and PASETO are both used for token-based authentication and authorization. While JWT offers flexibility and broad support, PASETO prioritizes security by default, making it a simpler and safer option for modern applications.

featured image - JWT vs PASETO: What's the Best Tool for Generating Secure Tokens?

Both JWT (JSON Web Token) and PASETO (Platform-Agnostic Security Tokens) are technologies used to generate secure tokens. Secure and scalable token-based authentication and authorization are essential for any modern web and API applications. JWT is known for its flexibility and broad support across platforms. However, this flexibility can sometimes lead to cryptographic misconfigurations. PASETO is a newer addition to the token generation stack, simplifying token security with built-in cryptographic tools. In this article, I will compare the differences between JWT and PASETO.

What is JWT?

JWT stands for JSON Web Token. It is a compact, URL-safe, self-contained token used to securely transfer information between interested parties. It is mainly used for authentication and authorization in stateless and highly scalable web applications. This compact token contains all the necessary information to validate the user's identity.

JWT Structure

JWT token has three parts. These parts are separated by “.“

<Header>.<Payload>.<Signature>

Header

The header specifies the type of token (JWT) and the signing algorithm (eg: HS256, RS256)

{ "alg": "HS256", "typ": "JWT" }

Payload

This contains claims. Claims can be standard, public claims, or private claims.

Standard: Predefined by JWT (iss, exp etc ..)
Public claims: Custom claims defined by the application
Private claims: Custom claims shared between issuer and consumer.

{
  "sub": "123456",
  "name": "myname",
  "admin": true,
  "iat": 1516239022
}

Signature

This is the part that ensures integrity and authenticity. It is created by combining the header, payload, a secret key, and the signing algorithm:

HMACSHA256(
    base64UrlEncode(header) + "." + base64UrlEncode(payload),
    secret
)

Here’s a sample of a JWT token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTYiLCJuYW1lIjoibXluYW1lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.6GOSrUxRcqk5AjW7E6Xn-T3B9BE5Gy8iX3oyTsVswIY

What is PASETO?

PASETO (Platform-Agnostic Security Tokens) is a new standard for creating secure, stateless tokens, widely used in authentication and authorization. Built to address the shortcomings of JSON Web Tokens (JWT), PASETO prioritizes security, simplicity, and ease of use, making it an excellent choice for modern applications.

PASETO Structure

PASETO token consists of three or four parts. Each part is separated by “.“ Below is the structure of the PASETO token.

<Version>.<Purpose>.<Payload>.<optional_footer>

Version: This indicates the protocol version used to generate the token.
Purpose: There are two options here. Local (In this case, the token will be encrypted) and Public (In this case, the token will be signed).
Payload: This contains the Claims and Data. For the local tokens, the payload is encrypted with a secret key and base64 encoded. For public tokens, the payload is in plain text and base64 encoded.
Footer: This is an optional section. And contains non-sensitive information.

JWT vs PASETO

Criterion	JWT	PASETO
Design Philosophy	1. Emphasizes flexibility and broad support.2. Allows a wide variety of algorithms, which has led to security issues3. Relies heavily on developers to choose secure configurations	1. Prioritizes security by default 2. Limiting the algorithm choices to secure defaults. This avoids common cryptographic pitfalls 3. Simplifies implementation by less flexible but safer
Algorithm Choice	1. Supports a wide range of algorithms, including some that are outdated or insecure (e.g., RS256, HS256, and even the "none" algorithm if not properly configured).	1. Only allows safe and modern algorithms (e.g., AES-GCM).
Usability and Simplicity	1. Offers flexibility, but this can lead to misconfigurations.2.Developers must carefully manage signing, verification, and algorithm selection to avoid security risks.	1.Easier for developers to use securely because it enforces secure defaults.2. Provides two main purposes: Local tokens (v2.local) for symmetric encryption and Public tokens (v2.public) for public key cryptography.
Security	1. Vulnerable to various attacks if not implemented carefully, such as: Algorithm confusion (e.g., using "none").2. Key mismanagement3. Security depends heavily on developers knowledge and configuration.	1. Strong emphasis on cryptographic safety2. Removes the risk of algorithm confusion attacks by avoiding algorithm negotiation altogether3. Explicit versioning ensures compatibility and security
Token Size	Size is larger if asymmetric signatures are used	Usually results in smaller and more consistent size. This is because of the fixed length header and more efficient cryptographic algorithms.
Backward Compatibility	Algorithm negotiation risks	Explicit versioning helps with backward compatibility.
Statefulness	JWT is stateless by default. And it is harder to implement statefulness.	PASETO also stateless by default. PASETO tokens are smaller and more efficient. This helps it be easily stored and scalable in a database backend systems. Hence PASETO tokens are easy to be converted to a Stateful token.
Storage	Tokens are stored in the client side to be sent to server as part of the request. 1. JWT can be stored as part of the Cookies with HttpOnly and Secure flags on. 2. It can be stored in local storage but vulnerable to XSS attack 3. It can be stored to SessonStorage but still vulnerable to XSS attack	Tokens are stored in the client side to be sent to server as part of the request. 1. PASETO can be stored as part of the Cookies with HttpOnly and Secure flags on. 2. It can be stored in local storage. The ‘local‘ mode adds encryption to the token and more confidentiality. 3. This also can be stored in SessionStorage. The ‘local‘ mode adds more confidentiality.
Scalability	JWT is widely used and proven to be highly scalable. But JWT token size is large and has expensive cryptographic operations. This design can introduce inefficiencies.	PASETO token size is smaller and has faster algorithms with better default security. This is optimized for much higher scalability than JWT.
Confidentiality	By default, JWT is only encoded. Anybody who has access to the token can look into the data. While the token's signature ensures integrity, it doesn't hide the dataOptional:To achieve confidentiality, the developer can implement JSON Web Encryption (JWE). Implementing JWE adds significant complexity to token management. Developers must handle encryption and decryption keys and ensure they use secure configurations.	In 'local' mode, by default, PASETO uses authenticated encryption to encrypt the payload. This offers confidentiality and integrity. The payload is completely hidden even if somebody gets access to the token.
Revocability (Revocability refers to the ability to invalidate tokens before their expiration, ensuring that unauthorized or compromised tokens can no longer be used)	No built-in mechanism to support the revocability. Must rely on external mechanisms to support this. Below are some strategies you can employ to support the token Revocability. 1)Token Blacklist: Store the blacklisted tokens externally and validate. 2)Short Token Lifetimes with Refresh Tokens: Requires refresh tokens to mitigate exposure. 3)Key Rotation: Supported but requires manual handling. Revocation overhead is higher due to larger token size and slower cryptography	No built-in mechanism to support the revocability. Must rely on external mechanisms to support this. Below are some strategies you can employ to support the token Revocability. 1)Token Blacklist: Store the blacklisted tokens externally and validate. This can be faster than JWT because of smaller token sizes. 2)Short Token Lifetimes with Refresh Tokens:Requires refresh tokens to mitigate exposure. 3)Key Rotation: Built-in versioning simplifies the key rotation. Revocation overhead is lower due to smaller token size and better cryptographic algorithms
Implementation Complexity (The complexity depends on the ease of use, available libraries, cryptographic requirements, and design considerations)	**Advantages:
\ 1) Widespread Adoption: Extensive library support in every major programming language. Many frameworks include built-in tools for creating, verifying, and signing. 2)Simple Token Signing: JWT only requires signing the header and payload using a shared secret key or a private key. **Challenges:
\ 1) Custom Claims:Adding a custom claim to JWT token can lead to token bloating if not managed carefully. 2)No Built-in Encryption:If you have to encrypt your play load, you have to use JSON Web Encryption (JWE). This adds more complexity 3)Key Management:Managing multiple keys for signing (JWS) and encrypting (JWE) tokens requires secure storage. 4)Misconfiguration: Bad configuration of the algorithm can lead to security vulnerabilities. You must be cautious with token validation, revocation, and expiration.	**Advantages:
\ 1) Simpler Design:It has simplified the structure and enforcing best cryptographic practices. Unlink JWT both signing and encryption and handled natively. 2)Built-in Security:'local' mode by default encrypts the token. This eliminates the need for developer intervention. 'public' mode signs the payload without encrypting. 3)Key rotation and versioning:Built-in versioning simplifies the upgrade to the latest cryptographic standards and key rotation. **Challenges:
\ Less adoption.
Use Cases	1) Broad and flexible 2) Suitable for general-purpose applications where flexibility and widespread compatibility are necessary.3. Works well in ecosystems that already have strong JWT support and tooling.	1) Ideal for scenarios where security is the highest priority, and flexibility is less critical. 2)Great for systems where you want to ensure security by default behavior.

Summary

Both JWT and PASETO are widely used for stateless authentication and authorization, but their strengths and weaknesses make them more suitable for different use cases.

You should choose JWT if:

You are working on a legacy system where JWT is already part of it or the framework is already supporting JWT
Require compatibility with OAuth2, OpenID connect
You really know the cryptographic algorithms you are dealing with. (Ex: JWE for the encryption).

You should choose PASETO if:

You’re looking for a by-default secure solution that reduces the risk of misconfiguration
The application requires encryption by default (PASETO local mode) or frequent key rotation.
You are building your application from scratch and looking for a more secure token mechanism
You are building a system that prioritizes small tokens and efficient cryptographic operations.