Токен пользователя истек что это

Токен CSRF истекает во время входа в систему

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

первый вопрос: возможно ли вообще (по spring security 3.2.4)? Без отключения csrf.

Я попытался использовать security= «none» для страницы входа и весны seciruty «login_check», но он не работает, у меня есть перенаправление бесконечности или я получил ошибку, что нет сопоставления для url»myhost/login_check».

второй вопрос: Как я могу это сделать?

3 ответов

рекомендуемое решение

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

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

второй вариант

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

обратите внимание, однако, что вам нужно действительно копать и переопределять внутренние механизмы spring-security, а именно:

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

Третий способ

у вас может быть небольшой javascript, который вызывает страницу no-op на вашем сервере регулярно (непосредственно перед таймаутом сеанса), таким образом, продлевая сеанс. Это приводит к бесконечному таймауту сеанса, только если браузер включен все время, поэтому аспект DOS смягчается.

Ok, последнее решение

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

вы можете сделать это, например, установив пользовательский RequestMatcher в HttpSecurity:

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

вы также можете сделать свою защиту CSRF полагаться на cookies, а не на состояние сеанса на стороне сервера. Spring Security полностью поддерживает это.

вы получите тайм-аут, Если ваш cookie истекает. Это хорошо масштабируется, так как это в основном без состояния (с точки зрения сервера).

Источник

Проверка истечения токена в Firebase авторизации. Проясняем некоторые моменты

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

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

Немного про JWT токен и проверку его истечения

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

Получение idToken осуществляется путем

Этот метод возвращает promise объект, так как эта операция асинхронна и занимает некоторое время для того чтобы сходить на сервер google и получить ответ.

Для того чтобы на клиенте, в JS, проверить истечение этого токена, необходимо его декодировать. В этом нам поможет библиотека https://github.com/auth0/node-jsonwebtoken, которая позволяет без всякой проверки токена на валидность декодировать как header так и payload. Мы знаем что jwt токен состоит из трех частей

Как триггерится и как работает событие смены токена

Из документации firebase, ясно, что для того чтобы отловить событие обновления токена нужно подписаться на событие onIdTokenChanged.

onIdTokenChanged(nextOrObserver, error, completed) returns function()

Источник

Токен Авторизации

В настоящее время киберпреступность стала проблемой мирового уровня. Например, Дмитрий Самарцев, директор BI.ZONE в сфере кибербезопасности привёл на Всемирном экономическом форуме следующие цифры. В 2018 году ущерб мировой экономики от киберпреступности составил по его словам 1.5 триллиона долларов. В 2022 году прогнозируются потери уже в 8 триллионов, а в 2030 ущерб от киберпреступлений может превысить 90 триллионов долларов. Чтобы уменьшить потери от киберпреступлений, необходимо совершенствовать методы обеспечения безопасности пользователей. В настоящее время существует множество методов аутентификации и авторизации, которые помогают реализовать надежную стратегию безопасности. Среди них многие эксперты выделяют в качестве лучшей авторизацию на основе токенов.

До появления токена авторизации повсеместно использовалась система паролей и серверов. Сейчас эта система всё ещё остаётся актуальной из-за своей простоты и доступности. Используемые традиционные методы гарантируют пользователям возможность получить доступ к их данным в любое время. Это не всегда эффективно.

Рассмотрим эту систему. Как правило, идеология их применения базируется на следующих принципах:

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

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

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

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

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

Типы токенов авторизации

Токены авторизации различаются по типам. Рассмотрим их:

Устройства, которые необходимо подключить физически. Например: ключи, диски и тому подобные. Тот, кто когда-либо использовал USB-устройство или смарт-карту для входа в систему, сталкивался с подключенным токеном.

Устройства, которые находятся достаточно близко к серверу, чтобы установить с ним соединение, но оно не подключаются физически. Примером такого типа токенов может служить «magic ring» от компании Microsoft.

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

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

Процесс токен авторизации

Авторизация с помощью токена происходит следующим образом. Сначала человек запрашивает доступ к серверу или защищенному ресурсу. Запрос обычно включает в себя ввод логина и пароля. Затем сервер определяет, может ли пользователь получить доступ. После этого сервер взаимодействует с устройством: ключ, телефон, USB или что-то ещё. После проверки сервер выдает токен и отправляет пользователю. Токен находится в браузере, пока работа продолжается. Если пользователь попытается посетить другую часть сервера, токен опять связывается с ним. Доступ предоставляется или, наоборот, запрещается на основе выданного токена.

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

Что такое аутентификация на основе токенов?

аутентификация по паролю (обычное запоминание комбинации символов)

аутентификация по биометрии (отпечаток пальца, сканирование сетчатки глаза, FaceID)

Аутентификация токенов требует, чтобы пользователи получили сгенерированный компьютером код (или токен), прежде чем им будет предоставлен доступ в сеть. Аутентификация токенов обычно используется в сочетании с аутентификацией паролей для дополнительного уровня безопасности (двухфакторная аутентификация (2FA)). Если злоумышленник успешно реализует атаку грубой силы, чтобы получить пароль, ему придется обойти также уровень аутентификации токенов. Без доступа к токену получить доступ к сети становится труднее. Этот дополнительный уровень отпугивает злоумышленников и может спасти сети от потенциально катастрофических нарушений.

Как токены работают?

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

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

Хотя эти традиционные системы аутентификации токенов все еще действуют сегодня, увеличение количества смартфонов сделал аутентификацию на основе токенов проще, чем когда-либо. Смартфоны теперь могут быть дополнены, чтобы служить генераторами кодов, предоставляя конечным пользователям коды безопасности, необходимые для получения доступа к их сети в любой момент времени. В процессе входа в систему пользователи получают криптографически безопасный одноразовый код доступа, который ограничен по времени 30 или 60 секундами, в зависимости от настроек на стороне сервера. Эти мягкие токены генерируются либо приложением-аутентификатором на устройстве, либо отправляются по запросу через SMS.

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

Безопасно ли использование токенов?

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

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

Рекомендации по аутентификации на основе токенов

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

Правильный веб-токен. Хотя существует целый ряд веб-токенов, ни один из них не может обеспечить ту же надежность, которую предоставляет веб-токен JSON (JWT). JWT считается открытым стандартом (RFC 7519) для передачи конфиденциальной информации между несколькими сторонами. Обмен информацией осуществляется цифровой подписью с использованием алгоритма или сопряжения открытого и закрытого ключей для обеспечения оптимальной безопасности.

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

Что такое JSON веб-токены?

В своей компактной форме веб-токены JSON состоят из трех частей, разделенных точками: заголовок, полезная нагрузка, подпись. Поэтому JWT выглядит обычно выглядит следующим образом: «xxxx.yyyy.zzzz».

Заголовок состоит из двух частей: типа токена, которым является JWT, и используемого алгоритма подписи, такого как HMAC SHA256 или RSA.

Тоже не понял, что за прикол там происходит.

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

Выходные данные представляют собой три строки Base64-URL, разделенные точками, которые могут быть легко переданы в средах HTML и HTTP, будучи при этом более компактными по сравнению со стандартами на основе XML, такими как SAML.

Почему стоит использовать токены авторизации?

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

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

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Token, refresh token и создание асинхронной обертки для REST-запроса

В данном туториале мы кратко разберем, как реализовываются REST-запросы к API, требующие, чтобы пользователь был авторизован, и создадим асинхронную «обертку» для запроса, которая будет проверять авторизацию и своевременно ее обновлять.

Данные для авторизации

Сделав REST-запрос к api, куда мы отправили логин и пароль, в ответ мы получаем json следующего формата (значения взяты рандомные и строки обычно длиннее):

Полей в ответе может быть больше, например еще «token_type», «expires_on» и т. д., но, для данной реализации, нам нужны только три поля, приведенные выше.
Давайте их рассмотрим подробнее:

Получение токена

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

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

Функция для сохранения токена в sessionStorage:

Функция для получения токена:

Таким образом мы получили токен с полями «access_token», «refresh_token» и «expires_in» и сохранили его в sessionStorage для дальнейшего использования.

Обновление токена

Токен полученный нами ранее имеет ограниченное время жизни, которое задано в поле «expires_in». После того как его время жизни истечет, пользователь не сможет получить новые данные, отправляя данный токен в запросе, поэтому нужно получить новый токен.

Получить токен мы можем двумя способами: первый способ это заново авторизовавшись, отправив логин и пароль на сервер. Но это нам не подходит, т. к. заставлять пользователя каждый раз заново вводить данные авторизации по истечению какого-то отрезка времени — неправильно, это надо делать автоматически. Но хранить где-то в памяти пару логин/пароль для автоматической отправки небезопасно, именно для этого и нужен «refresh_token», который был получен ранее вместе с «access_token» и хранится в sessionStorage. Отправив данный токен на другой адрес, который предоставляет api, мы сможем получить в ответ новый «свежий» токен.

Функция для обновления токена

С помощью кода выше мы перезаписали токен в sessionStorage и теперь по новой можем отправлять запросы к api.

Создание функции-обертки

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

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

Функция-обертка

С помощью кода выше мы создали функцию, которая будет добавлять токен к запросам в api. На эту функцию мы можем заменить fetch в нужных нам запросах, где требуется авторизация и для этого нам не потребуется менять синтаксис или добавлять в аргументы еще какие-либо данные.
Просто достаточно будет «импортнуть» ее в файл и заменить на нее стандартный fetch.

Источник