Angular-auth-oidc-client: Id_Token is rejected because of timing issue when server hour is different then client hour

[DanielGherasim]

I have both my OIDC Server and Angular App using angular-auth-oidc-client instance hosted on a server which has local time set to Belgium (UTC +1).

My PC is on UTC +2 so I receive the authorizedCallback Validation, iat rejected id_token was issued too far away from the current time error because of that.

When I change server's time to be the same with my PC time, it works fine.

We should somehow take that into consideration when measuring time passed since the token was issued, given that it is very possible that clients of the library will not have the same local time as the server where the application is hosted.

[damienbod]

@danielgherasim Thanks.

both apps, client and server should use UTC time. If this is not the case, this is a bug. I will check that the OIDC lib uses UTC time, and fix this if required. The STS server is out of scope here, but you should check this as well.

Greetings Damien

[DanielGherasim]

@damienbod I am using Identity Server 4. I will also check if it is using UTC time when generating the token, thanks.

[KollarM]

@damienbod, Hi. We are also facing issues with iat validation. Many users has some clock skew. Best would be to fix this on the client computers, but this is not so easy.

In http://openid.net/specs/openid-connect-implicit-1_0.html they are mentioning in section 2.2.1. ID Token Validation, point 8 - "The iat Claim can be used to reject tokens that were issued too far away from the current time, limiting the amount of time that nonces need to be stored to prevent attacks. The acceptable range is Client specific."
The specification is using words like MUST, SHOULD and CAN.
In this case it is CAN. It will be very nice to make this iat validation optional. Will really help in our scenario.

Kind regards.

Martin

[damienbod]

@KollarM The validation can be set to a value which makes it optional.

https://github.com/damienbod/angular-auth-oidc-client/blob/master/API_DOCUMENTATION.md#max_id_token_iat_offset_allowed_in_seconds
Set this value to something large

Greetings Damien

[KollarM]

Your fast response is very appreciated. Yes setting max_id_token_iat_offset_allowed_in_seconds to something big is also the only thing I was able to think of as a quick fix (probably permanent as well).
Thanks a lot for confirming this way.

[chinkan]

Hi,

I have same problem too, I cannot force client to use UTC time. So, how can I fix it? Could I use client local time and convert to UTC?

[damienbod]

@chinkan I tried to reproduce this but could not. I used a server configured with time zone +1. I then set my local computer with +6 and - 6 hours time zone, and got no error.

Greetings Damien

[KollarM]

@damienbod, @chinkan , the problem is probably not the UTC time, but the client local clock is out of sync with global time. I think it can be reproduced by turning off time synchronization and manually setting some time. For example in windows 7 - https://www.addictivetips.com/windows-tips/disable-time-synchronization-in-windows-7/

[jsubiratsgirbau]

You can reproduce the error by changing manually the time in your computer. Thanks @KollarM !

[damienbod]

closing this, this seems to be a configuration issue with your servers. Please reopen is you still have problems.

[philippesc]

@KollarM The validation can be set to a value which makes it optional.

https://github.com/damienbod/angular-auth-oidc-client/blob/master/API_DOCUMENTATION.md#max_id_token_iat_offset_allowed_in_seconds
Set this value to something large

Greetings Damien

Well but when the token validation fails.. (e. g. Token not expired?: 1560767199000 > 1560767239983 (false)) then there is no way to handle this, right?

[Lempkin]

Hi, same problem here. My computer is on GMT+0100, and server is in UTC time. Tokens have a 1hour duration. So when I receive token exp is 10:05 for instance, and on my computer (client) it's already 10:05.
In lib code we can see

var nowWithOffset = new Date().valueOf() + offsetSeconds * 1000;
var tokenNotExpired = tokenExpirationValue > nowWithOffset;

new Date() returns the actual time on client computer (not UTC), I think this issue should be reopened

[damienbod]

Hi @Lempkin I validated this and new Date().valueOf() returns UTC time in ms correctly

[NateJBeck]

We were demoing on two mobile devices, one of which had been set to local time, one of which was set to several timezones earlier. The local machine worked fine, the other did not. Solved by turning ON time synchronization on the machine experiencing the error. Thanks to KollarM for the useful comment.

[bonaparte89]

We are seeing this issue as well.
We are using Code-Flow-Autologin (from sample) and latest package version (11.2.1). Our Identity-Server4 runs on an AWS in UTC.

We deployed the same application to different QA-Environments. (Same build only swapped config).
Now some people can easily access the page just as expected.
Others report not able to access QA 1 and 2.
Others report not able to access QA 1 or 2.
Everyone has tried Chrome, Brave, Firefox. The issue persists even if the browser changed.
The application is being served by CloudFront.

Issue here always the iat max offset validation.
Where you could say the browser for some reason doesn't take the utc time on QA1 but on QA2 it does.
So we actually can say it's not related to the system-time-settings.

Of course I could increase the maxIatOffsetSeconds to ... 12 hours. But this actually can't be the solution.
After disabling the maxiatoffsetseconds .. the id-token expired validation jumps in. arg.

[bonaparte89]

Ok I found a solution which works. I have cloned the lib, created a package and pushed the new code to our QAs.
Everything runs just as it should now.

I had to change
new Date () => new Date(new Date().toUTCString()).valueOf()

I will create a PR tomorrow.

[JefredAllan]

Looks like this issue still exists. I'm using Azure AD.