JWT and PASETO Tokens

In the world of web development, authentication and authorization are crucial aspects of building secure and reliable applications. One way to achieve these goals is by using tokens, which are digital assets that represent a user's identity or a specific privilege. In this blog post, I'll delve into the world of tokens, specifically focusing on JSON Web Tokens (JWT) and PASETO, two popular formats for representing and managing tokens in web applications.

I will start exploring the basics of tokens and their use cases, Then, we'll dive deeper into JWT and PASETO, discussing their pros and cons.

What is a token?

A tokens is a digital asset that represents cliams or assertions about a user or a client that requesting access to a resource.

Suppose you have a web application that allows users to log in and access their account, which contains sensitive information. In that case, you need to make sure that only authorized users can access their account. One stateless way to achieve this is by using tokens. You can issue a token to a user after they log in, and then the user can use that token to access their account.

Tokens are used in many different contexts, including authentication, authorization, and access control.

What is a JWT?

JWT stands for JSON Web Token. It is a self-contained token format that is used to securely transmit information between parties as a JSON object.

JWT consists of three parts: a header, a payload, and a signature.

JWT Header

The header is a JSON object that descript the cryptographic operations applied to the token such as the algorithm used to sign the token, and the type of token.

For example, the following header indicates that the token is signed using the HMAC SHA-256 algorithm:

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

The header is then Base64Url encoded to form the first part of the JWT.

JWT Payload (aka Claims or Assertions)

The payload is a JSON object that contains the claims or assertions about the user or client that is requesting access to a resource.

For example, the following payload contains registered claims such as the issued at, subject, and expiration time, as well as custom claims such as the user's ID and email address:

{
  "sub": "1234567890",
  "id:" "123",
  "email": "user@example.com",
  "iat": 1516239022,
  "exp": 1516239022
}

The payload is then Base64Url encoded to form the second part of the JWT.

JWT Signature

The signature is a string that verifies the integrity of the token and ensured that us has not been tempared with. It is created by combining the encoded header, the encoded payload, and a secret key, and then signing the resulting string using the algorithm specified in the header.

For example, the following signature is created by combining the encoded header, the encoded payload, and the secret key secret using the HMAC SHA-256 algorithm:

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

The signature is then Base64Url encoded to form the third part of the JWT as final segment.

Note: There are two cryptographic algorithms that are used to sign and verify tokens: symmetric and asymmetric. In symmetric cryptography, the same key is used to sign and verify the token. In asymmetric cryptography, two keys are used: a public key to sign the token and a private key to verify the token. You will need to use asymmetric cryptography if you want your token to be consumed by a different application to the one that created it, you can use asymmetric-key algorithms such as RSA or ECDSA. Whereas if your JWT is going to be consumed by the same application that created it, then the appropriate choice is a (simpler and faster) symmetric-key algorithm like HMAC-SHA256 with a random secret key, This is what we’ll use

And this was a quick overview of JWT, pretty simple and configurable right ?! and this simplicity is the main reason for its popularity. But also this simplicity is the main reason for its security issues. Now let's discuss the main security issues with JWT.

JWT Security Issues

JWT is not encrypted by default:

JWT is a self-contained token, which means that it contains all the information needed to verify its integrity and validity. This means that the token can be decoded and verified without the need to make a database call or a network request. This is great for performance, but it also means that the token can be decoded and verified by anyone, including the client.

This is a problem because the client can tamper with the token and change its claims. For example, the client can change the expiration time of the token to extend its validity period.

One of the security issue with that is that the alg header can be set to none which means that the token is not signed. This means that anyone can create a token with any claims they want and use it to access protected resources.

To solve this issue, you need to make sure that the alg header is set to a secure algorithm such as HS256 or RS256. Also to make sure that the token is not tampered with, you need to check the claims in the payload and make sure that they are valid, Such as the expiration time, the issuer, and the audience.

Choosing the right algorithm:

As we mentioned before, the alg header specifies the algorithm used to sign the token. There are many algorithms to choose from, there are number of algorithms to not use, such as HS256 and RS256. These algorithms are not secure and can be easily cracked. To solve this issue, you need to make sure that the alg header is set to a secure algorithm such as if you are using symmetric key, you can use HS384 or HS512 or if you are using asymmetric key, you can use RS384 or RS512.

JWT has a several security issues, to mitigate security risks associated with JWT, consider the following best practices:

Use HTTPS: This is the most important step you can take to secure your application. It ensures that the token is transmitted securely over the network and cannot be intercepted by a third party.
Use a secure algorithm: As we mentioned before, the alg header specifies the algorithm used to sign the token.
Protect the secret key: The secret key is used to sign the token, so it should be kept secret. You should store the secret key in a secure location such as a vault or a key management system.
Use short-lived tokens: The longer a token is valid, the more time an attacker has to crack it.

Here are some articles that you can read to learn more about JWT security issues and best practices:

What is PASETO?

PASETO stands for Platform-Agnostic SEcurity TOkens. It is a new token format that aims to provide more secure and flexible alternative to JWT.

PASETO is designed to be platform-agnostic, which means that it can be used in any programming language and on any platform without the need for additional libraries or dependencies, in contrast JWT relay on the JSON format and require libraries to parse and manipulate the tokens.

Unlike JWT, which gives you more than enough rope with which to hang yourself PASETO is designed to be secure by default. It uses the latest and most secure cryptographic algorithms, and it does not allow you to choose your own algorithms.

Also the most important thing about PASETO for me is that its payload is always encrypted, which means that it is not possible to tamper with the token and change its claims, and any change to the token will result in an invalid token.

From the features above we can say PASETO is resolved all the security issues that we mentioned before with JWT.

PASETO Token Structure

PASETO tokens are structured as follows:

[version].[purpose].[payload].[footer]

v2.local.QAxIpVe-ECVNI1z4xQbm_qQYomyT3h8FtV8bxkz8pBJWkT8f7HtlOpbroPDEZUKop_vaglyp76CzYy375cHmKCW8e1CCkV0Lflu4GTDyXMqQdpZMM1E6OaoQW27gaRSvWBrR3IgbFIa0AkuUFw.UGFyYWdvbiBJbml0aWF0aXZlIEVudGVycHJpc2Vz

This decodes to

Versions:

The version of the protocol used to encrypt the token, for now there are two versions: v1 and v2.

This allows for backward compatibility and makes it easy to add new features to the protocol.

Purpose:

The purpose of the token, there are two purposes: local and public. local inidiactes that the token is encrypted using a symmetric key, and public indicates that the token is encrypted using an asymmetric key.

If the token is v1 :
- When the purpose is local, the token is encrypted using the AES-256-CTR algorithm.
- And when the purpose is public, the token is encrypted using the RSA-OAEP-256 algorithm.
If the token is v2 :
- when the purpose is local, the token is encrypted using the XChaCha20-Poly1305 algorithm.
- and when the purpose is public, the token is encrypted using the EdDSA algorithm.

Payload:

The payload is the main content, its encrypted accroding to the version and purpose of the token. after decryption, the results is three parts:

Body: which is the actual payload of the token.

  {
    "id": "007",
    "exp": "2039-01-01T00:00:00+00:00"
  }

Nonce: is used in both encryption and message authentication process, e.g. 400c48a557be10254d235cf8c506e6fea418a26c93de1f05.
Authentication tag: authenticate the encrypted message and its associated unencrypted data, e.g. 6914af581ad1dc881b1486b4024b9417.

The footer is an optional field that can be used to store additional information about the token, unlink the payload, the footer is not encrypted, it's Base64Url encoded and appended to the token.

PASETO Security Features

PASETO achieves platform agnosticism by using binary encoding format, as opposed to JWT which uses JSON format. this makes PASETO tokens more compact and effiecient to parse and transmit over the network or store in a database, which can be important for applications that require high performance.

PASETO include a version number in the token header, this allows for backward compatibility and makes it easy to add new features to the protocol. JWT does not include a version number in the token header, and relay on the server to determine the version of the token.

PASETO designed to be more secure than JWT, it uses modren cryptographic algorithms such as XChaCha20-Poly1305 and EdDSA to encrypt and sign the token. Also PASETO encrypt the payload by default. All this helped PASETO to persists against the security issues such as tempring, replay, forgery, and key confusion.

PASETO does't have a lot of cons but the most known one is that it's not has a resources like JWT, but I think it's just a matter of time.

Here are some resources that you can read to learn more about PASETO:

Conclusion

Tokens are a crucial aspect of web development, enabling secure authentication and authorization. In this article, we've explored the concept of tokens and compared two popular token generators: JWT and PASETO. We've delved into the pros and cons of each method and examined the underlying structure of both. By the end of this article, you should have a deeper understanding of these essential tools and be better equipped to choose the right one for your development needs.

Islamghany