The Most Important JSON Web Token (JWT) Setting You're Probably Ignoring

Hello everybody, I'm Nick and in this video, I'm going to show you the most important JSON Web Token (JWT) setting that you have probably ignored, but you shouldn't. Leaving this value in its default setting can actually be very problematic, and you will find out about it by the behavior looking like a bug.

Introduction

In this article, I will explain what this setting is, how it works, why it's bad and problematic, and most importantly, how you can change it to a better value.

But before we dive into it, I want to mention that I have recently launched my brand new course, "From Zero to Hero: Logging in .NET" on dometrain.com. Logging is such a fundamental aspect of every .NET application, and this course covers all the basics, advanced features, and even high-performance techniques. To celebrate the launch, I'm offering a massive 20% discount code to the first 400 participants. Just use the code "log20" during checkout to claim your discount.

Understanding JSON Web Tokens (JWT)

Before we delve into the specific setting, let's briefly understand what JSON Web Tokens (JWT) are and their importance in securing APIs. JWT is an open standard for securely transmitting information between parties as a JSON object. It contains claims that are digitally signed to ensure integrity. Many companies and developers widely use JWT for authorized access to their APIs.

Each JWT consists of three parts: header, payload, and signature. The payload contains the claims, which are additional pieces of information such as user ID, roles, and expiration time.

The Default Setting Problem

The setting we are going to discuss is known as "clock skew." Clock skew refers to a time difference between different servers or services in a distributed computing environment. As JWT is often used in such distributed environments, it's essential to handle clock skew properly.

The default clock skew setting in many JWT libraries, including .NET, is surprisingly high. In .NET, the default clock skew is set to 5 minutes, meaning that tokens considered to be short-lived, such as those with a 15-minute expiration time, are actually valid for 20 minutes (15 minutes + 5 minutes clock skew).

The Consequences of the Default Clock Skew

The high default value of the clock skew can lead to a range of issues. One of the most common problems is that tokens that should have expired are still considered valid due to the time difference between servers. This behavior can cause unexpected security vulnerabilities and bugs in your application.

For example, imagine an API that accepts JWT for authentication. If a token is expired, it should result in an unauthorized response. However, with the default clock skew setting, tokens that have technically expired can still be accepted by the API because of the time drift between servers.

Configuring the Clock Skew Setting

To address this issue, it's crucial to adjust the clock skew setting in your application. By reducing the clock skew, you can minimize the validity period of expired tokens and prevent potential security risks.

In .NET, you can configure the clock skew setting through the token validation parameters. By setting a more reasonable and smaller value, such as 1 minute, you can ensure that expired tokens are properly rejected.

The Importance of Setting the Clock Skew Value

One of the key settings that developers should pay attention to when using a token-based authentication system is the clock skew value. In this article, we will discuss the default value of the clock skew and why it is crucial to override this setting for improved system security.

Understanding the Default Clock Skew Value

By default, the clock skew value is set to 5 minutes. This means that if you have a token with a lifetime of 15 minutes, in reality, it will be valid for 20 minutes due to the default clock skew. This default value of 5 minutes is surprisingly high, considering the potential security risks it poses.

The reason behind the high default value of the clock skew might be the fact that the authentication library has been around for a long time and changing this value would require significant modifications. However, it is important to note that this default value is not suitable for most scenarios and should be overridden.

Choosing the Appropriate Clock Skew Value

While the exact value to override the clock skew setting can be subject to debate, it is generally recommended to set it between 5 and 30 seconds. However, setting it to 30 seconds should be considered a maximum limit and pushing it any further is not advisable.

It is worth mentioning that Arkham IV Computing Edge cloud service actually recommends a clock skew of just 5 seconds. Any clock skew value exceeding 5 seconds on a network-synchronized machine indicates a potential issue with the machine itself. Considering this recommendation, it is safe to conclude that the maximum clock skew value should not exceed 15 seconds in a worst-case scenario.

The Consequences of Ignoring the Clock Skew Setting

Now, let's explore the consequences of ignoring the clock skew setting. If we keep the default value of 5 minutes, a token would actually be valid for an extra 10 minutes due to the two-way nature of time-related elements in the token. The clock skew affects both the expiration time and the "not valid before" time.

To demonstrate this, let's comment out the clock skew setting and modify the "not valid before" time in the token. We set the "not valid before" time to one minute in the future and extend the expiration time to two minutes. Surprisingly, even with these modifications, the token remains valid because the default clock skew value of 5 minutes extends its validity for an additional 10 minutes.

Enforcing a Lower Clock Skew for Improved Security

Given the potential security risks and unexpected behavior associated with the default clock skew, it is highly recommended to take control of this setting and enforce a lower value based on your system's context. By lowering the clock skew value, you will implicitly enhance the security of your systems.

Moreover, adjusting the clock skew setting to a more reasonable value will align the token's validity strictly with the desired duration, minimizing any potential unauthorized access. This proactive approach to security will ensure that your token-based authentication system operates as expected.

To conclude, we encourage you to consider the clock skew value for your systems and share your thoughts. What clock skew setting are you using? Leave a comment down below and let us know. Thank you for reading, and happy coding!In conclusion, the default clock skew setting in jwt libraries, including .net, can lead to unexpected behaviors and security vulnerabilities in your application. it is essential to review and adjust this setting to ensure the validity and security of your tokens. by reducing the clock skew, you can prevent expired tokens from being accepted and mitigate potential risks.

remember, securing your application's apis is crucial, and understanding the intricacies of jwt settings is an essential aspect of achieving that security.