jwt token время жизни

JSON Web Token и sliding expiration в web-приложении

В web-приложениях наиболее распространенным методом аутентификации до настоящего времени являлось использование файлов cookies, которые хранят идентификатор серверной сессии и имеют свой срок годности (expiration date). При этом существует возможность эту дату автоматически продлевать при очередном обращении пользователя на сервер. Такой подход носит название sliding expiration.

Сам JWT, также как и cookie, имеет свою дату ‘протухания’ (expiration date) и в простейшем случае используется следующим образом:

Подход с использованием refresh token довольно сильно усложняет, как клиентский, так и серверный код. При этом он требует хранить все refresh token-ы пользователей вместе с Client id и прочей дополнительной информацией.

В случае если же Вы хотите, чтобы пользователь бесконечно мог пользоваться ресурсом после входа, предлагается реализовать sliding expiration для токенов. То есть в простейшем (первом) случае при получении access token-а сервер при приближении к expiration date (или же каждый раз) отправляет пользователю новый access token со сдвинутой датой. Такой подход в случае кражи токена, приводит к тому, что злоумышленник бесконечно может пользоваться ресурсом.

Во втором случае производится то же самое, но только для refresh token-а.

Вот собственно все подходы, которые мне удалось найти. Я же в свою очередь хотел бы ограничиться для простоты только одним access token-ом, но при этом иметь sliding expiration и возможность менять права и ограничивать в доступе токен, в случае его кражи.

Для этого я бы добавил в токен новое поле RefreshDate (дату после которой токен требуется обновить; должна быть меньше, чем expiration date, если она указана) и в базу данных в таблицу пользователей только одно поле — MinRefreshDate. Это поле должно хранить минимальную дату RefreshDate, которая валидна для пользователя. При этом для обновлении токена MinRefreshDate должна быть непустой и всегда должна быть меньше, чем RefreshDate самого токена, который требуется обновить.

При этом процесс использования выглядел бы примерно так:

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

Источник

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

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

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

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

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

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

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

Источник

Пять простых шагов для понимания JSON Web Tokens (JWT)

Представляю вам мой довольно вольный перевод статьи 5 Easy Steps to Understanding JSON Web Tokens (JWT). В этой статье будет рассказано о том, что из себя представляют JSON Web Tokens (JWT) и с чем их едят. То есть какую роль они играют в проверке подлинности пользователя и обеспечении безопасности данных приложения.

Для начала рассмотрим формальное определение.

JSON Web Token (JWT) — это JSON объект, который определен в открытом стандарте RFC 7519. Он считается одним из безопасных способов передачи информации между двумя участниками. Для его создания необходимо определить заголовок (header) с общей информацией по токену, полезные данные (payload), такие как id пользователя, его роль и т.д. и подписи (signature).
Кстати, правильно JWT произносится как /dʒɒt/

Приложение использует JWT для проверки аутентификации пользователя следующим образом:

Структура JWT

Шаг 1. Создаем HEADER

Хедер JWT содержит информацию о том, как должна вычисляться JWT подпись. Хедер — это тоже JSON объект, который выглядит следующим образом:

Шаг 2. Создаем PAYLOAD

Payload — это полезные данные, которые хранятся внутри JWT. Эти данные также называют JWT-claims (заявки). В примере, который рассматриваем мы, сервер аутентификации создает JWT с информацией об id пользователя — userId.

Мы положили только одну заявку (claim) в payload. Вы можете положить столько заявок, сколько захотите. Существует список стандартных заявок для JWT payload — вот некоторые из них:

Эти поля могут быть полезными при создании JWT, но они не являются обязательными. Если хотите знать весь список доступных полей для JWT, можете заглянуть в Wiki. Но стоит помнить, что чем больше передается информации, тем больший получится в итоге сам JWT. Обычно с этим не бывает проблем, но все-таки это может негативно сказаться на производительности и вызвать задержки во взаимодействии с сервером.

Шаг 3. Создаем SIGNATURE

Подпись вычисляется с использование следующего псевдо-кода:

Алгоритм base64url кодирует хедер и payload, созданные на 1 и 2 шаге. Алгоритм соединяет закодированные строки через точку. Затем полученная строка хешируется алгоритмом, заданным в хедере на основе нашего секретного ключа.

Шаг 4. Теперь объединим все три JWT компонента вместе

Теперь, когда у нас есть все три составляющих, мы можем создать наш JWT. Это довольно просто, мы соединяем все полученные элементы в строку через точку.

Вы можете попробовать создать свой собственный JWT на сайте jwt.io.
Вернемся к нашему примеру. Теперь сервер аутентификации может слать пользователю JWT.

Как JWT защищает наши данные?

Очень важно понимать, что использование JWT НЕ скрывает и не маскирует данные автоматически. Причина, почему JWT используются — это проверка, что отправленные данные были действительно отправлены авторизованным источником. Как было продемонстрировано выше, данные внутри JWT закодированы и подписаны, обратите внимание, это не одно и тоже, что зашифрованы. Цель кодирования данных — преобразование структуры. Подписанные данные позволяют получателю данных проверить аутентификацию источника данных. Таким образом закодирование и подпись данных не защищает их. С другой стороны, главная цель шифрования — это защита данных от неавторизованного доступа. Для более детального объяснения различия между кодированием и шифрованием, а также о том, как работает хеширование, смотрите эту статью. Поскольку JWT только лишь закодирована и подписана, и поскольку JWT не зашифрована, JWT не гарантирует никакой безопасности для чувствительных (sensitive) данных.

Шаг 5. Проверка JWT

В нашем простом примере из 3 участников мы используем JWT, который подписан с помощью HS256 алгоритма и только сервер аутентификации и сервер приложения знают секретный ключ. Сервер приложения получает секретный ключ от сервера аутентификации во время установки аутентификационных процессов. Поскольку приложение знает секретный ключ, когда пользователь делает API-запрос с приложенным к нему токеном, приложение может выполнить тот же алгоритм подписывания к JWT, что в шаге 3. Приложение может потом проверить эту подпись, сравнивая ее со своей собственной, вычисленной хешированием. Если подписи совпадают, значит JWT валидный, т.е. пришел от проверенного источника. Если подписи не совпадают, значит что-то пошло не так — возможно, это является признаком потенциальной атаки. Таким образом, проверяя JWT, приложение добавляет доверительный слой (a layer of trust) между собой и пользователем.

В заключение

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

Что дальше?

Источник

Шпаргалки по безопасности: JWT

Многие приложения используют JSON Web Tokens (JWT), чтобы позволить клиенту идентифицировать себя для дальнейшего обмена информацией после аутентификации.

JSON Web Token – это открытый стандарт (RFC 7519), который определяет компактный и автономный способ безопасной передачи информации между сторонами в виде объекта JSON.

Эта информация является проверенной и надежной, потому что она имеет цифровую подпись.
JWT могут быть подписаны с использованием секретного (с помощью алгоритма HMAC) или пары открытого / секретного ключей с использованием RSA или ECDSA.

JSON Web Token используется для передачи информации, касающейся личности и характеристик клиента. Этот «контейнер» подписывается сервером, чтобы клиент не вмешивался в него и не мог изменить, например, идентификационные данные или какие-либо характеристики (например, роль с простого пользователя на администратора или изменить логин клиента).

Этот токен создается в случае успешной аутентификации и проверяется сервером перед началом выполнения каждого клиентского запроса. Токен используется приложением в качестве “удостоверения личности” клиента (контейнер со всей информацией о нем). Сервер же имеет возможность проверять действительность и целостность токена безопасным способом. Это позволяет приложению быть stateless (stateless приложение не сохраняет данные клиента, сгенерированные за один сеанс для использования в следующем сеансе с этим клиентом (каждый сеанс выполняется независимо)), а процессу аутентификации независимым от используемых сервисов (в том смысле, что технологии клиента и сервера могут различаться, включая даже транспортный канал, хотя наиболее часто используется HTTP).

Соображения по поводу использования JWT

Даже если токен JWT прост в использовании и позволяет предоставлять сервисы (в основном REST) без сохранения состояния (stateless), такое решение подходит не для всех приложений, потому что оно поставляется с некоторыми оговорками, как, например, вопрос хранения токена.

Если приложение не должно быть полностью stateless, то можно рассмотреть возможность использования традиционной системы сессий, предоставляемой всеми веб-платформами. Однако для stateless приложений JWT – это хороший вариант, если он правильно реализован.

Проблемы и атаки, связанные с JWT

Использование алгоритма хеширования NONE

Подобная атака происходит, когда злоумышленник изменяет токен, а также меняет алгоритм хеширования (поле “alg”), чтобы указать через ключевое слово none, что целостность токена уже проверена. Некоторые библиотеки рассматривали токены, подписанные с помощью алгоритма none, как действительный токен с проверенной подписью, поэтому злоумышленник мог изменить полезную нагрузку (payload) токена, и приложение доверяло бы токену.

Для предотвращения атаки необходимо использовать библиотеку JWT, которая не подвержена данной уязвимости. Также во время проверки валидности токена необходимо явно запросить использование ожидаемого алгоритма.

Перехват токенов

Атака происходит, когда токен был перехвачен или украден злоумышленником и он применяет его для получения доступа к системе, используя идентификационные данные определенного пользователя.

Защита заключается в добавлении «пользовательского контекста» в токен. Пользовательский контекст будет состоять из следующей информации:

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

Код для создания токена после успешной аутентификации:

Код для проверки валидности токена:

Явное аннулирование токена пользователем

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

Одним из способов защиты является внедрение черного списка токенов, который будет пригоден для имитации функции «выход из системы», существующей в традиционной системе сеансов.

В черном списке будет храниться сборник (в кодировке SHA-256 в HEX) токена с датой аннулирования, которая должна превышать срок действия выданного токена.

Когда пользователь хочет «выйти», он вызывает специальную службу, которая добавляет предоставленный токен пользователя в черный список, что приводит к немедленному аннулированию токена для дальнейшего использования в приложении.

Хранилище черного списка:
Для централизованного хранения черного списка будет использоваться база данных со следующей структурой:

Управление аннулированиями токенов:

Раскрытие информации о токене

Эта атака происходит, когда злоумышленник получает доступ к токену (или к набору токенов) и извлекает сохраненную в нем информацию (информация о токене JWT кодируется с помощью base64) для получения информации о системе. Информация может быть, например, такой как, роли безопасности, формат входа в систему и т.д.

Способ защиты достаточно очевиден и заключается в шифровании токена. Также важно защитить зашифрованные данные от атак с использованием криптоанализа. Для достижения всех этих целей используется алгоритм AES-GCM, который обеспечивает аутентифицированное шифрование с ассоциированными данными (Authenticated Encryption with Associated Data – AEAD). Примитив AEAD обеспечивает функциональность симметричного аутентифицированного шифрования. Реализации этого примитива защищены от адаптивных атак на основе подобранного шифртекста. При шифровании открытого текста можно дополнительно указать связанные данные, которые должны быть аутентифицированы, но не зашифрованы.

То есть шифрование с соответствующими данными обеспечивает подлинность и целостность данных, но не их секретность.

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

Хранение токенов на стороне клиента

Если приложение хранит токен так, что возникает одна или несколько из следующих ситуаций:

Остается случай, когда злоумышленник использует контекст просмотра пользователя в качестве прокси-сервера, чтобы использовать целевое приложение через легитимного пользователя, но Content Security Policy может предотвратить связь с непредвиденными доменами.

Также возможно реализовать службу аутентификации таким образом, чтобы токен выдавался внутри защищенного файла cookie, но в этом случае должна быть реализована защита от CSRF.

Использование слабого ключа при создании токена

Если секрет, используемый в случае алгоритма HMAC-SHA256, необходимый для подписи токена, является слабым, то он может быть взломан (подобран c помощью атаки грубой силы). В результате злоумышленник может подделать произвольный действительный токен с точки зрения подписи.

Для предотвращения этой проблемы надо использовать сложный секретный ключ: буквенно-цифровой (смешанный регистр) + специальные символы.

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

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

Источник

JWT (JSON Web Token) автоматическое продление срока действия

Я хотел бы реализовать аутентификацию на основе JWT для нашего нового REST API. Но поскольку срок действия установлен в токене, можно ли его автоматически продлить? Я не хочу, чтобы пользователям нужно было входить через каждые X минут, если они активно использовали приложение в этот период. Это был бы огромный провал UX.

но продление срока действия создает новый токен (и старый по-прежнему действителен до истечения срока действия). И создание нового токена после каждого запроса звучит глупо для меня. Звучит как проблема безопасности, когда несколько токенов действительны одновременно. Конечно, я мог бы аннулировать старый используемый, используя черный список, но мне нужно будет хранить токены. И одним из преимуществ JWT является отсутствие хранения.

Я нашел, как Auth0 решил это. Они используют не только токен JWT, но и токен обновления: https://docs.auth0.com/refresh-token

но опять же, чтобы реализовать это (без Auth0), мне нужно будет хранить токены обновления и поддерживайте их срок годности. В чем же тогда реальная выгода? Почему бы не иметь только один токен (не JWT) и сохранить срок действия на сервере?

есть ли другие варианты? Использование JWT не подходит для этого сценария?

9 ответов

Я работаю в Auth0, и я участвовал в разработке функции токена обновления.

все зависит от типа приложения и вот наш рекомендуемый подход.

web-приложений

хорошим шаблоном является обновление токена до его истечения.

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

чтобы обновить токен, вашему API нужна новая конечная точка, которая получает действительный, не истекший JWT и возвращает тот же подписанный JWT с новым полем истечения срока действия. Затем веб-приложение будет хранить токен где-то.

мобильные/приложения

большинство родных приложений войти один раз и только один раз.

идея в том, что токен обновления никогда не истекает, и это может быть всегда обменивается на действительный JWT.

проблема с токеном, который никогда не истекает, заключается в том, что никогда значит никогда. Что делать, если вы потеряете свой телефон? Таким образом, он должен быть идентифицирован пользователем каким-то образом, и приложение должно предоставить способ отозвать доступ. Мы решили использовать имя устройства, например «iPad maryo». Затем пользователь может перейти в приложение и отозвать доступ к «iPad maryo».

другой подход-отозвать токен обновления на конкретное событие. Интересное событие-смена пароля.

мы считаем, что JWT не полезен для этих случаев использования, поэтому мы используем случайную строку и храним ее на нашей стороне.

в случае, когда вы сами обрабатываете auth (i.e не используйте провайдера, такого как Auth0), может работать следующее:

флаг «reauth» в бэкэнде базы данных будет установлен, когда, например, пользователь сбросил свой пароль. Флаг удаляется при следующем входе пользователя в систему.

кроме того, предположим, у вас есть политика, в соответствии с которой пользователь должен войти по крайней мере один раз каждые 72 часа. В этом случае логика обновления маркера API также проверит дату последнего входа пользователя из базы данных пользователя и запретит/разрешит обновление маркера на этой основе.

я возился при перемещении наших приложений в HTML5 с RESTful apis в бэкэнде. Решение, которое я придумал, было:

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

более сложная стратегия может быть реализована для удовлетворения бездействия пользователя (например, пренебречь открытой вкладкой браузера). В этом случае вызов маркера renew должен включать ожидаемое время истечения, которое не должно превышать определенное время сеанса. Приложения следите за последним пользовательским взаимодействием соответственно.

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

альтернативным решением для аннулирования JWTs без дополнительного безопасного хранения на бэкэнде является реализация нового jwt_version столбец integer в таблице users. Если пользователь хочет выйти из системы или истечь срок действия существующих токенов, они просто увеличивают

статьи обновить токены: когда их использовать и как они взаимодействуют с JWTs дает хорошую идею для этого сценария. Некоторые моменты:-

посмотрите auth0 / angular-jwt в AngularJS

Я фактически реализовал это в PHP, используя клиент Guzzle, чтобы сделать клиентскую библиотеку для api, но концепция должна работать для других платформ.

в основном, я выпускаю два токена, короткий (5 минут) и длинный, который истекает через неделю. Клиентская библиотека использует промежуточное ПО для попытки обновления короткого маркера, если он получает ответ 401 на какой-либо запрос. Затем он попробует исходный запрос снова, и если он смог обновить, получит правильный ответ, прозрачно для пользователя. Если это не удалось, он просто отправит 401 пользователю.

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

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

Late edit: перечитывая этот месяц после того, как он был свеж в моей голове, я должен указать, что вы можете отменить доступ при обновлении короткого токена, потому что это дает возможность для более дорогих вызовов (например, вызов в базу данных, чтобы узнать, был ли пользователь запрещен), не платя за него при каждом вызове к вашим услугам.

jwt-autorefresh

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

полный пример реализации

отказ от ответственности: я хранитель

Как насчет такого подхода:

нам не требуется дополнительная конечная точка для обновления токена в этом случае. Был бы признателен за любой feedack.

я решил эту проблему, добавив переменную в данные токена:

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

на стороне клиента, если он получил EXPIRED_TOKEN response, он должен автоматически обновлять токен, отправляя запрос на обновление на сервер. Это прозрачно для пользователь и автоматически заботится о клиентском приложении.

метод обновления на сервере должен проверить, действителен ли токен:

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

Источник