Clock skew and tokens

Question

I need help to understand how clock skew works. We define clock skew to deal with time variation between two parties. But, my confusion is:

1. we have all information such as token created time and expiration time in the token itself
2. tokens can be validated
3. tokens are created on the server

So, why do we need clock skew? Can anyone give me the example for how it works and in which scenarios it can cause problems or benefits?

Answer 1

There is a clock skew in the Microsoft JWT validation middleware. It is set by default to 5 mins and cannot be less (300 seconds/5 minutes)

There is a token validation parameter called ClockSkew, it gets or sets the clock skew to apply when validating a time. The default value of ClockSkew is 5 minutes. That means if you haven't set it, your token will be still valid for up to 5 minutes. If you want to expire your token on the exact time; you'd need to set ClockSkew to zero as follows,

 services.AddAuthentication("Bearer").AddJwtBearer("Bearer", options =>
        {
            options.Authority = "https://localhost:44347";
            options.TokenValidationParameters = new TokenValidationParameters
            {
                ValidateAudience = false,
                ValidateLifetime = true,
                ClockSkew = TimeSpan.Zero
            };
        });

Answer 2

Lets consider a short lived access token. When I make a request to a server the server will check to see if my token has expired. How does it check that well it knows when the token was created and it knows what time it is now. Most access tokens expire after an hour but it really depends on how it was set up in the auth server. So if the token was created more than an hour ago its expired and the user is informed of that. This is why we try to ensure that servers are in sync with NTP.

Lets consider first what exactly is clock skew. What if we have two auth servers? How do you know that they will have the same time? What if they are in fact off by a few minutes. One server will return that the token has expired and the other wont. If you are a small company this probably doesn't matter.

Now consider if you are a big search engine company with servers all around the world. Lets say its the fall of 2016 and daylight savings time kicks in. Now you have some servers running on one time and others running at another. Maybe just maybe some country decides to change when they start daylight savings time and boom a bunch of tokens get invalidated for no reason. disclaimer I do not work for said search engine company. I just watched this happen and this is my theory as to what happened.

Why do we need clock skew.

You dont need it it but if you have two auth servers you could have it. So you should probably deal with it. https://softwareengineering.stackexchange.com/a/245182/160992

Answer 3

Okay so clock skew is not happening in your machine. By default, clock skew is set to 5 minutes. This is the reason the JWT was not expiring at the desired time.

Answer 4

This means setting a tolerance for the token expiration time in ValidateLifetime mode.ClockSkew means tolerance for this inconsistency (between the time and time of the token issuer and its consumer).

Clock skew amount specifies the allowed time difference (in seconds) between the server and client clocks when validating the exp and nbf claims. The recommended default value is 5.