Clock skew leniency setting

[KalleOlaviNiemitalo]

Dependencies

JwtConsumerBuilder.setAllowedClockSkewInSeconds(int secondsOfAllowedClockSkew) has been available since jose4j-0.4.0~100.

Feature Request

Please add a setting that lets Jenkins accept the JWT from Azure AD even if the Not Before (nbf) time is a few minutes later than the current time of the server where the Jenkins controller is hosted. This would be a workaround for environments in which the clock of that server is synchronized from a local Active Directory domain controller whose clock lags behind the clock used by Azure AD.

With version 185.v3b416408dcb1 of the Azure AD plugin, clock skew like that causes the login to fail, and jenkins.err.log shows:

2021-12-26 13:52:02.148+0000 [id=12]	WARNING	o.e.j.s.h.ContextHandler$Context#log: Error while serving https://REDACTED/jenkins/securityRealm/finishLogin
org.jose4j.jwt.consumer.InvalidJwtException: JWT (claims->{REDACTED,"iat":1640526888,"nbf":1640526888,"exp":1640530788,REDACTED}) rejected due to invalid claims or other invalid content. Additional details: [[6] The JWT is not yet valid as the evaluation time NumericDate{1640526722 -> 26.12.2021 klo 15.52.02 EET} is before the Not Before (nbf=NumericDate{1640526888 -> 26.12.2021 klo 15.54.48 EET}) claim time.]
	at org.jose4j.jwt.consumer.JwtConsumer.validate(JwtConsumer.java:459)
	at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:304)
	at org.jose4j.jwt.consumer.JwtConsumer.process(JwtConsumer.java:426)
	at org.jose4j.jwt.consumer.JwtConsumer.processToClaims(JwtConsumer.java:171)
	at com.microsoft.jenkins.azuread.AzureSecurityRealm.validateIdToken(AzureSecurityRealm.java:453)
	at com.microsoft.jenkins.azuread.AzureSecurityRealm.doFinishLogin(AzureSecurityRealm.java:393)
	at java.base/java.lang.invoke.MethodHandle.invokeWithArguments(Unknown Source)
	at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:393)

The plugin configures the JWT validation settings here:

https://github.com/jenkinsci/azure-ad-plugin/blob/3b416408dcb1215580da92cd8ee64d41f85b41a4/src/main/java/com/microsoft/jenkins/azuread/Utils.java#L88-L94

[KalleOlaviNiemitalo]

It seems Azure AD already tries to prevent clock skew problems by making the Issued At (iat) and Not Before (nbf) claims five minutes earlier than the actual time of issue. However, this does not suffice if the clock skew exceeds five minutes.

[timja]

Could the system get its clock fixed instead? 5 minutes is already quite generous

[KalleOlaviNiemitalo]

Yeah I'm pursuing that solution as well.

[KalleOlaviNiemitalo]

Got the clock fixed, but I'd still like to have this fallback available in case the problem recurs.