Mastering JWT authentication

Introduction

Working in cybersecurity, I have recently spent some time doing technology watch and developing my skills on a recurring topic when developing web and mobile applications: authentication.
I won't go so far as to say that authentication is neglected in the applications I test, but I have noticed that it is often a factor of bad choice of architecture and often an axis of compromise due to its lack of understanding by developers.
That's why today, I propose my point of view, how I see authentication, how we should conceptualize it.

Authentication concept

Authentication is the process of verifying the identity of a user, system or device. It ensures that the people or things accessing a service or resource are who they claim to be.
The concept of authentication is based on verifying a user's identity using mechanisms such as user IDs and passwords, digital certificates or authentication tokens.
Authentication is not to be confused with authorization, which is the determination of what actions an authorized user can perform on a service or resource. For example, an authenticated person may have access to a certain amount of functionality in an application, but not be allowed to modify the source code.
In short, authentication is about verifying the identity of a user, while authorization is about determining what actions the user can perform.

Authentication by AccessToken

A JWT (JSON Web Token) is a base64 encoded data object that is used to authenticate requests sent to an API.

It is structured (according to RFC 7519) in three parts separated by dots:

1. Header: contains information about the type of JWT and the algorithm used to sign the token.
2. Payload: contains data useful to the service that will receive the JWT, such as the user's identifier and role information. These data are called "claims".
3. Signature: is a hash of the header and payload signed with a secret key. This allows to verify that the JWT has not been altered during its transmission.

To use a JWT for authentication, a service must first send the client an authentication request, usually by asking the client to enter its credentials. If the credentials are correct, the service sends the client a JWT signed with a secret key. The client stores this JWT and sends it with each subsequent request to authenticate to the service. The service then checks the signature of the JWT and if it is valid, it authorizes the client's request.

One advantage of JWT token is that it allows you to store data in the payload. This allows you to avoid making additional requests to the database to retrieve information about the user. For example, you can store the user's role in the payload and use it to determine what actions the user is allowed to perform. And of course, as it is simply a base64 encoded data object, it is very easy to decode it and read its content from the client side. As a result, JWTs are not suitable for storing sensitive information such as passwords or credit card numbers. They should only be used to store non-sensitive information such as user IDs, roles, and permissions.

Note: To use a JWT for authentication, it is agreed that it is sent in the HTTP header named "Authorization" and preceded by the word "Bearer".

The need to persist the connection

The JWT is a real asset for modern application architectures, however when it is issued, it is recommended to give it a shortest lifetime possible for security purposes. We will therefore introduce a mechanism that allows to have JWTs with a very short lifetime without having to re-enter its identifiers each time. A refresh token is a token used to obtain a new JWT after the old one has expired. It is typically used in conjunction with a JWT in authentication systems to allow users to remain authenticated over a long period of time without having to re-enter their credentials. Here's how it typically works:

1. Upon initial authentication, the service sends the client a JWT along with a refresh token. The JWT has a limited lifetime (traditionally 15 minutes) while the refresh token has a longer lifetime (for example, 1 week or 1 month).
2. When the JWT expires, the client sends the refresh token to the service to request a new JWT.
3. If the refresh token is valid, the service sends the client a new JWT and a new refresh token. Don't forget to invalide the old refresh token.

Note: To ensure maximum security in your application, a refresh token should be stored exclusively in a cookie with the HTTP attributes "secure" and "http-only". This means that unlike the JWT it cannot be retrieved by the user's web browser.

But what are our advantages with this system?

The main advantage of using refresh tokens is that they reduce the risk of sensitive data leakage. Indeed, since JWTs have a limited lifetime, they cannot be stolen and used indefinitely to authenticate. Here are some advantages of JWT and refresh token authentication:

• Security: JWTs are signed and therefore have integrity, which means they cannot be altered during transmission. Moreover, as refresh tokens are stored on the server side and not on the client side, they are much more difficult to steal than JWTs. In case of compromise of a user's JWT, the attacker will have 15 minutes maximum. In case of compromise of the whole platform, you just have to invalidate all refreshToken and your users will be forced to reconnect.
• Ease of use: With JWT and refresh token authentication, there is no need to store client credentials on the server side. This simplifies the authentication process and makes it more scalable.
• Scalability: JWTs can be easily integrated into many systems and architectures, making it a flexible and adaptable authentication solution.
• Performance: JWTs are small in size and can therefore be easily passed in HTTP headers, improving application performance.
• Protocol independence: JWTs can be used with any protocol and on any network, making it a very portable authentication solution.

Conclusion

I hope that this article has been able to inform you, and even allow you to make architectural choices thanks to this information.