Мой провайдер идентификаторов возвращает значение, которое Keycloak не понимает.Что я могу сделать? - PullRequest
Новая
       44

Мой провайдер идентификаторов возвращает значение, которое Keycloak не понимает.Что я могу сделать?

0 голосов
/ 10 октября 2018

Я использую Keycloak с внешним сервером OAuth, используемым в качестве поставщика идентификаторов.

Когда я пытаюсь войти в систему, Keycloak отправляет запрос обратного канала аутентификации, в котором сервер OAuth отвечает JWT.

При декодировании этого JWT Keycloak завершается неудачей с этим исключением 

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

Кажется, что значение exp слишком велико.Не удается ли расшифровать брелок для ключей?мой сервер OAuth отправляет неверное значение?Что я могу сделать для правильного декодирования этого выдоха?

Ответы [ 2 ]

0 голосов
/ 09 июня 2019

Дело в том, что с момента опубликования черновика JWT (февраль 2014 года) спецификация изменилась относительно временной метки "exp".В окончательной спецификации, опубликованной в мае 2015 года, (https://tools.ietf.org/html/rfc7519#section-4.1.4) просто требуется числовая дата.

Итак, RFC не диктует ширину числового представления, и я предполагаю, что это означает (изсторона приложения (как keycloak), что мы должны использовать достаточно широкое целое число (64-разрядное), чтобы не переполнять.

Эта ситуация может стать более раздражающей в ближайшем будущем из-за проблемы Y2038 (32-разрядное целое число со знаком не может представлять даты после (примерно) 19 января 2038 г.

0 голосов
/ 12 октября 2018

Насколько я понимаю, кажется, что провайдер идентификаторов, который я пытаюсь использовать, не соответствует спецификации JWT.Действительно, спецификация JWT заявляет следующее

Заявка "exp" (время истечения) определяет время истечения, после которого JWT НЕ ДОЛЖЕН быть принят для обработки.Обработка претензии "exp" требует, чтобы текущая дата / время ДОЛЖНА быть до даты / времени истечения срока, указанного в претензии "exp".Реализаторы МОГУТ предусмотреть небольшую задержку, обычно не более нескольких минут, для учета перекоса часов.Его значение ДОЛЖНО быть числом, содержащим значение IntDate.Использование этого утверждения НЕОБЯЗАТЕЛЬНО.

Другими словами, когда установлено значение exp, оно должно быть значением типа int, содержащим количество секунд с момента EPOCH.

...