Некорректный токен или время жизни токена истекло что делать

При настройке компонента Identity and Access Manager (далее также IAM) необходимо указать параметры времени жизни токена и время ожидания авторизации. Параметры по умолчанию разработаны с учетом одновременно и стандартов безопасности, и нагрузки на Сервер. Вы можете менять эти параметры в соответствии с политиками вашей организации.

IAM автоматически повторно выпускает токен, когда срок его действия истекает.

В таблице ниже перечислены параметры времени жизни токена по умолчанию.

Параметры времени жизни токена

Время жизни по умолчанию (в секундах)

Идентификационный токен (id_token)

Идентификационный токен, используемый клиентом OAuth 2.0 (то есть Kaspersky Security Center 13.2 Web Console или веб-интерфейсом Kaspersky Industrial CyberSecurity). IAM отправляет идентификатор токена, который содержит информацию о пользователе (то есть профиль пользователя) клиенту.

Токен доступа (access_token)

Токен доступа, используемый клиентом OAuth 2.0 для доступа к серверу ресурсов от имени владельца ресурса, определенного IAM.

Обновить токен (refresh_token)

Клиент OAuth 2.0 использует этот токен для повторной выдачи идентификационного токена и токена доступа.

В таблице ниже приведено время ожидания для auth_code и login_consent_request.

Параметры времени ожидания авторизации

Время ожидания по умолчанию (в секундах)

Код авторизации (auth_code)

Время ожидания обмена кода токена. Клиент OAuth 2.0 отправляет этот код на сервер ресурсов и взамен получает токен доступа.

Время ожидания запроса на вход (login_consent_request)

Время ожидания для делегирования прав пользователя клиенту OAuth 2.0.

Для получения дополнительной информации о токенах см. веб-сайт OAuth.

Как на клиенте определить время жизни токена JWT?

Подскажите пожалуйста, как на клиенте определить время жизни токена (JWT-token и JWT-passport), если закончилось время, я его храню в localstorage?
У меня интернет магазин все товары загружаю во Vuex при загрузке сайта, т.е. к серверу обращаюсь один раз.
Я никак не могу сообразить как бы правильно проверить токен, если я не обращаюсь к серверу.
Если время закончилось, то его нужно удалить.

Вопрос задан более трёх лет назад
5677 просмотров

8 комментариев

Простой 8 комментариев

potapchino

alex @potapchino
не надо ничего проверять на клиенте. если нужно проверить токен делайте пинг на сервер.
Alex правильно сказал, считай что клиент это самое небезопасное место которое может быть)
Sport-code @Sport-code Автор вопроса

Alex,
А можно, если не за труднит примерчик, что за пинг и куда его вставить (в click или в хук или еще куда-то)
И как часто пинг посылать?
Спасибо

potapchino

alex @potapchino

Sport-code, ну делаете метод апи, типо — site.com/api/auth/ping, и на этот эндпоинт делаете запрос, а он обратно 204 если все ок или 401 если токен протух. это как один из многих вариантов как можно это реализовать. запрос можно по интервалу посылать. можно лонгполинг или вебсокеты вообще применит, наверное, я не пробовал.

Sport-code @Sport-code Автор вопроса

У меня метод Login генерирует токен на 15 мин. и в интерцеторе я добавляю Authorization, со стороны сервера все нормально, и когда expirate то возвращается 401.
Если запрос router.beforeEach как использовать или watch, можно как-то?

Sport-code @Sport-code Автор вопроса

Честно, я так и не понял как правильно сделать?!
Хорошо, если на клиенте, то мне нужно сделать примерно так
от текущей даты сравнить EXP ?

potapchino

alex @potapchino

Честно, я так и не понял как правильно сделать?!

сравниваете exp с Date.now(). если exp меньше или равен .now() значит токен протух. плюс нужно будет сделать поправку на часоывае пояяса наверное.

p.s. только у клиента может быть некорректно встывлена дата на компьютере, вот вам еще одна причина не делать проверку токена на клиенте

Sport-code @Sport-code Автор вопроса

Alex,
Да, я уже разобрался, спасибо, на клиенте сделал вроде работает.
Хочу попробовать теперь на сервер запрос делать через BeforeEach

Решения вопроса 0
Ответы на вопрос 3

Kozack

Alex @Kozack Куратор тега Vue.js
Thinking about a11y

Вместе с токеном должено возвращаться время жизни токена.
Если такого нет, то в момент получения токена стоит сохранять время его создания и срок жизни.
Если срок жизни вам не известен, и сервер не предоставляет никакого инструмента для проверки токена, тогда вам стоит написать обёртку вогруг сетевого интерфейса: после обращения к АПИ, если сервер возвращает ошибку токен — получить новый и повторить запрос.

Ответ написан более трёх лет назад
Нравится 1 1 комментарий
Sport-code @Sport-code Автор вопроса

Да, вот возращает

Я просто не знаю как правильно проверить истекло время или нет, думаю через router.beforeEach или watch
и в них сделать обращение к серверу?
Т.к. выше писали что на клиенте не проверять лучше

У вас есть время жизни токена, его и проверяйте в router.beforeEach. Больше ничего не надо.
Alex Александр Дроздов О чем вы говорите?
Если на клиенте злоумышленник изменит поле с временем жизни токена, токен от этого не станет «жить» дольше и на сервере все равно не пройдет и запрос отклонится.
Пинговать сервер в добавок к тому, что у вас на руках время жизни токена — это дикость какая-то.

Ответ написан более трёх лет назад

potapchino

alex @potapchino

проверяйте в router.beforeEach

spoiler

а если например злоумышленник изменит на клиенте например тот же exp в 10 раз, то получается что токен невалидный становится. но мы об этом не знаем, т.к. мы не пингуем сервер и не делаем вообще каких-то запросов(автор выше написал) и не верифицируем токен на клиенте. а если верифицировать на клиенте, то нам нужен секрет(на клиенте хранить секрет, wat?), ну или публичный ключ, но тогда у нас должна болеть голова о том чтобы на клиенте всегда был верный публичный ключ. + например сегодня у нас поле exp, а завтра бекендеру моча в голову ударила и он генерит токены с полем expiration_time — опять нужно следить. не легче пинговать сервер периодически? мб мои примеры надуманные, поправьте меня если я в чем то не прав, просто возможно я не очень прошарен в этой теме, а автору посоветовал вариант основанный на своем опыте.

Alex, Не надо вообще думать о валидации на клиенте. Валидация на клиенте нужны лишь для того, чтоб пользователю что-нибудь показывать. Например мы подсвечиваем поле, если он недопустимые символы вводит или оставляет поле пустым. Все. Дальше валидация идет на сервере и там мы уже все проверяем.
Злоумышленник может делать на клиенте все что угодно и обойти любые проверки, потому что клиент находится у него. Но нам на это плевать, мы полагаемся на серверную валидацию и ни о чем не думаем.

potapchino

alex @potapchino
WebDev, не понял если честно при чем тут валидация данных, когда речь о токенах идет
Alex, Валидация токена.

Время жизни на клиенте самого токена проверять не надо:
1. JWT может быть httpOnly, иначе это прямой удар по безопасности в виде возможности сXSSить этот токен скриптами
2. У пользователя на ПК время может отличаться от серверного. Допустим, время жизни JWT — 5 минут, а у пользователя часы спешат на 6 минут. Этой разницы недостаточно, чтобы SSL не установилось, зато достаточно, чтобы твой скрипт навсегда зациклился в попытке получить «свежий» токен, думая, что он несвежий

Поэтому делаешь так:
После успешного получения JWT ставишь в localStorage текущее время пользователя (пренебрегая разницей между действительным временем истечения и временем исполнения твоей функции — оно скорее всего не будет превышать пинг пользователя + 100мс). Каждый запрос прерываешь с помощью какого-нибудь https://github.com/axios/axios#interceptors В этом «прерывателе» смотришь в localStorage и если прошло 50-80% (тут оставляем запас, потому что мы выше пренебрегли разницей + сам запрос может длится некоторое время [например, это могут быть сетевые задержки, или запрос будет лежать в очереди, пока воркеры заняты или какие-то запросы бэкенда в БД будут происходить до валидации JWT] + часы пользователя могут идти быстрее серверных и дать лишние пару микросекунд) времени жизни JWT — отправляешь сперва запрос на рефреш этого токена, а потом уже отправляешь сам запрос.

Ответ написан более трёх лет назад
Sport-code @Sport-code Автор вопроса
Спасибо )))
А по проще никак нельзя?
Сложновато без примера. %)
Ваш ответ на вопрос

Войдите, чтобы написать ответ

vue

Vue.js

Как задать компоненту динамический фон?

1 подписчик
14 часов назад
24 просмотра

vue

Vue.js

Почему не срабатывает @error при ошибке загрузки ifarme?

1 подписчик
вчера
29 просмотров

Зачем нужен Refresh Token, если есть Access Token?

Недавно мы в Voximplant улучшали авторизацию в SDK. Посмотрев на результаты, я несколько опечалился, что вместо простого и понятного токена их стало две штуки: access token и refresh token. Которые мало того что надо регулярно обновлять, так еще документировать и объяснять в обучающих материалах. Помня, что в OAuth два токена нужны в основном из-за разных сервисов, на которых они используются (даже вопрос на stackoverflow есть), а у нас такой сервис один, я несколько офигел и пошел на второй этаж вытрясать души из разработчиков. Ответ получился неожиданным. Его нет на stackoverflow. Зато он есть под катом.

Зачем вообще нужны токены

При разработке приложений, общающихся с сервером, обычно вылезают следующие этапы:

Зачем нужен первый токен

Есть много разных токенов. Обычные, криптографические, «access key», «session token», разные схемы получения, использования и revoke. При этом одна из ключевых идей заключается в том, что если кто нехороший получит чужой токен, то самое неприятное, что случится — это доступ похитителя к сервису, от которого токен похищен. Пароль, тот самый, который один на все сервисы, похититель не получит. А пользователь, если поймет, что кроме него к сервису получил доступ кто-то другой, может токен отозвать. После чего получить себе новый, имея логин и пароль.

Зачем нужен второй токен

В OAuth 2 и некоторых других схемах авторизации (например, у нас) есть не один, а целых два токена. Первый, access token, используется при запросах к серверу (например, при логине). У него есть два свойства: он многоразовый и короткоживущий. Наш, к примеру, живет 48 часов, а у кого-то 30 минут. Время выбирается на основании того, как используется сервис. Второй, refresh token, используется для обновления пары access и refresh токенов. У него тоже есть два свойства, обратные первому токену: он одноразовый и долгоживущий. Совсем долгоживуший, наш живет месяц.

Схема использования у токенов следующая:

Пользователь логинится в приложении, передавая логин и пароль на сервер. Они не сохраняются на устройстве, а сервер возвращает два токена и время их жизни
Приложение сохраняет токены и использует access token для последующих запросов
Когда время жизни access token подходит к концу (приложение может само проверять время жизни, или дождаться пока во время очередного использования сервер ответит «ой, всё»), приложение используетrefresh token, чтобы обновить оба токена и продолжить использовать новый access token

Примерно так это все объяснено в документации OAuth, на Википедии, в нашей документации. И такое объяснение не отвечает на вопрос нафига. Зачем нужны два токена, если можно обойтись одним? В вопросе на stackoverflow даны несколько объяснений уровня «ну, access token можно менее надежно хранить чем refresh token и не бояться использовать вне HTTPS соединений. Например, хранить access token на frontend, а refresh token на backend» или «refresh token используется для доступа к заведомо безопасному сервису, а access token’ом потом можно тыкать во всякие подозрительные места и не очень бояться, что его сольют». Это может быть разумно для авторизации через Facebook и последующего использования без HTTPS. Но у нас-то везде HTTPS! И сервис у нас тоже один, наш. Зачем нам второй токен?

Зачем на самом деле нужен второй токен

Все оказалось и проще, и сложнее чем я думал. Следите за руками:

Случай 1: Боб узнал оба токена Алисы и не воспользовался refresh

В этом случае Боб получит доступ к сервису на время жизни access token. Как только оно истечет и приложение, которым пользуется Алиса, воспользуется refresh token, сервер вернет новую пару токенов, а те, что узнал Боб, превратятся в тыкву.

Случай 2: Боб узнал оба токена Алисы и воспользовался refresh

В этом случае оба токена Алисы превращаются в тыкву, приложение предлагает ей авторизоваться логином и паролем, сервер возвращает новую пару токенов, а те, что узнал Боб, снова превратятся в тыкву (тут есть нюанс с device id, может вернуть ту же пару что и у Боба. В таком случае следующее использование refresh токена превратит токены Боба в то, что изображено справа).

Таким образом, схема refresh + access токен ограничивает время, на которое атакующий может получить доступ к сервису. По сравнению с одним токеном, которым злоумышленник может пользоваться неделями и никто об этом не узнает.

Блог компании Voximplant
Информационная безопасность
Веб-разработка
Программирование
Разработка мобильных приложений

Задание максимального времени истечения токена

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

Токен в ArcGIS – это строка зашифрованной информации, содержащая имя пользователя, время окончания действия токена и другую специальную информацию. После передачи пользователю токена он может работать с порталом, до тех пор пока срок действия токена не истечет. По истечении этого срока пользователю придется снова вводить свои учетные данные.

На портале используются три разных типа токенов:

Токен ArcGIS — токен, сгенерированный через конечную точку sharing/rest/generateToken .
Токен доступа OAuth — токен, сгенерированный в процессе аутентификации OAuth2.
Токен обновления OAuth — токен, используемый для создания новых токенов доступа OAuth по истечении срока их действия.

При создании нового токена рекомендуется указывать срок действия для токена. Максимальное значение, которое можно выбрать, зависит от типа генерируемого токена.

Токен ArcGIS — 14 дней (20,160 минут)
Токен доступа OAuth, при создании с типами предоставления Implicit или Client Credentials — 14 дней (20,160 минут)
Токен доступа OAuth, при создании с типом предоставления Authorization Code — 30 минут
Токен обновления OAuth — 90 дней (129,600 минут)

Если указано время истечения срока, превышающее эти значения, токен все равно будет сгенерирован, но его срок действия будет соответствовать максимальному значению, которое может быть создано для этого типа токена. Если время истечения срока действия не указано при создании токена, используется значение по умолчанию, которое варьируется для каждого типа токена:

Токен ArcGIS — 120 минут
Токен доступа OAuth, при создании с типами предоставления Implicit или Client Credentials — 120 минут
Токен доступа OAuth, при создании с типом предоставления Authorization Code — 30 минут
Токен обновления OAuth — 2 недели (20,160 минут)

Эти максимальные значения и значения по умолчанию не могут быть увеличены и могут быть уменьшены путем установки свойства maxTokenExpirationMinutes в ArcGIS Portal Administrator Directory . Значение свойства maxTokenExpirationMinutes применяется к каждому типу токена. Если это значение меньше максимального значения, но больше значения по умолчанию, будет затронуто только максимальное значение, а значение по умолчанию останется прежним. Если значение меньше максимального значения и значения по умолчанию, будут затронуты оба значения, а максимальное значение и значение по умолчанию будут соответствовать тому, что определено в maxTokenExpirationMinutes .

Хотя эти значения могут подходить для вашей организации, важно учитывать последствия безопасности для токена. Токен с более длительным сроком действия менее защищен. Ведь токен, перехваченный злоумышленником, тоже будет действовать, пока не истечет этот срок. И наоборот, более короткое время истечения является более безопасным, но менее удобным, поскольку участникам может потребоваться вводить свои имя пользователя и пароль чаще.

Чтобы изменить максимальное время истечения токена для всех трех типов токенов, выполните следующие действия. Указанное вами значение применяется ко всем участникам портала; вы не можете указать разные значения для конкретных участников или только для администраторов.

Войдите в ArcGIS Portal Directory в качестве администратора вашей организации.

Некорректный токен или время жизни токена истекло что делать