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>
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 |
|
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. |
|
Storage |
Tokens are stored in the client side to be sent to server as part of the request. |
Tokens are stored in the client side to be sent to server as part of the request. |
|
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 data**Optional:**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. |
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.
Reference
https://permify.co/post/jwt-paseto/#what-is-jwt
