This update adds a new configuration variable use_microseconds. It defaults to true even if it does not exist so that it does not break backwards compatibility. If you set it to false the DateTimeImmutable object that we pass to issuedAt() & expiresAt() will be built without microseconds.
By removing the microseconds from the DateTimeImmutable object, we are letting the lcobucci/jwt package know that we want an int and not a float. You can see this logic in the MicrosecondBasedDateConversion class that lcobucci/jwt uses to covert all RegisteredClaims::DATE_CLAIMS.
The reason that I think this is need this is because the specification can be interpreted as calling for seconds and not seconds with microseconds. The description for "iat" (Issued At) Claim calls for a "NumericDate value" which is defined at the bottom of the Terminology section. That definition even links to IEEE Std 1003.1, 2013 Edition, 2013 which clearly notes, "The divisions in the formula are integer divisions; that is, the remainder is discarded leaving only the integer quotient."
Additionally, we are working with an application that is utilizing Google Firebase. We have been in contact with them on continued issues we are having and they recent sent us this:
"Turns out in the third party Google jwt library, the iat field (and other similar "seconds since epoch time" fields) is assumed to be a Long, which means that float values like 123.456 will cause an error.
Can the OIDC provider be configured to return an integer for those fields?"
This update adds a new configuration variable
use_microseconds. It defaults totrueeven if it does not exist so that it does not break backwards compatibility. If you set it tofalsetheDateTimeImmutableobject that we pass toissuedAt()&expiresAt()will be built without microseconds.By removing the microseconds from the
DateTimeImmutableobject, we are letting thelcobucci/jwtpackage know that we want anintand not afloat. You can see this logic in the MicrosecondBasedDateConversion class thatlcobucci/jwtuses to covert allRegisteredClaims::DATE_CLAIMS.The reason that I think this is need this is because the specification can be interpreted as calling for seconds and not seconds with microseconds. The description for "iat" (Issued At) Claim calls for a "NumericDate value" which is defined at the bottom of the Terminology section. That definition even links to IEEE Std 1003.1, 2013 Edition, 2013 which clearly notes, "The divisions in the formula are integer divisions; that is, the remainder is discarded leaving only the integer quotient."
Additionally, we are working with an application that is utilizing Google Firebase. We have been in contact with them on continued issues we are having and they recent sent us this: