CODEWITHSUNDEEP
jsonjacksonkeycloakopenid-connect
Riduidel
Riduidel

Reputation: 22292

My id provider returns a value Keycloak doesn't understand. What can I do?

I'm using Keycloak with an external OAuth server used as id provider.

When I try to login, Keycloak send an authentication backchannel request in which the OAuth server replies with a JWT.

When decoding that JWT, Keycloak fails with this exception

Caused by: com.fasterxml.jackson.core.JsonParseException: Numeric value (1539167070926) out of range of int
 at [Source: (byte[])"{"sub":"20008203","aud":"Test-Keycloak","amr":["pwd","mobile"],"iss":"oauth","exp":1539167070926,"iat":1539163470926,"jti":"d24e5a11-1931-45a7-b77a-0c935ea40df8"}"; line: 1, column: 97]
    at com.fasterxml.jackson.core.JsonParser._constructError(JsonParser.java:1804)
    at com.fasterxml.jackson.core.base.ParserMinimalBase._reportError(ParserMinimalBase.java:663)
    at com.fasterxml.jackson.core.base.ParserBase.convertNumberToInt(ParserBase.java:869)
    at com.fasterxml.jackson.core.base.ParserBase._parseIntValue(ParserBase.java:801)
    at com.fasterxml.jackson.core.base.ParserBase.getIntValue(ParserBase.java:645)
    at com.fasterxml.jackson.databind.deser.std.NumberDeserializers$IntegerDeserializer.deserialize(NumberDeserializers.java:472)
    at com.fasterxml.jackson.databind.deser.std.NumberDeserializers$IntegerDeserializer.deserialize(NumberDeserializers.java:452)
    at com.fasterxml.jackson.databind.deser.impl.FieldProperty.deserializeAndSet(FieldProperty.java:136)
    at com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:288)
    ... 80 more

It seems like the exp value is too big. Is keycloak failing to decode ? is my OAuth server sending a bad value ? What can I do to have that expiration correctly decoded ?

Upvotes: 1

Views: 578

Answers (2)

Michail Alexakis
Michail Alexakis

Reputation: 1585

The fact is that since the JWT draft was published (Feb 2014) the spec has changed regarding to the "exp" timestamp. The final spec, published at May 2015, (https://www.rfc-editor.org/rfc/rfc7519#section-4.1.4) simply requires a numeric date.

So, the RFC does not dictate the width of the numeric representation, and i assume that means (from the side of an application as keycloak) that we should use a wide-enough integer (64-bit) so that we do not overflow.

This situation can become more annoying in the short future because of the Y2038 problem (a signed 32-bit integer cannot represent dates after (roughly) 19 Jan 2038)

Upvotes: 2

Riduidel
Riduidel

Reputation: 22292

As far as I understand, it seems like the id provider I try to use doesn't honor the JWT spec. Indeed, the JWT spec states the following

The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. The processing of the "exp" claim requires that the current date/time MUST be before the expiration date/time listed in the "exp" claim. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value MUST be a number containing an IntDate value. Use of this claim is OPTIONAL.

In other words, when exp is set, it must be an int value containing a number of seconds since EPOCH.

Upvotes: 1

Related Questions