Как я написал в разделе "Структура данных", в рамках моей статьи, email используется в качестве логина. Это отражено в схеме и в тексте раздела. Проверка уникальности email тут важна потому, что логин должен быть уникальным. Если найдено совпадение, значит пользователь уже регистрировался в приложении раньше. А в какой схеме это не так? Может я что-то просмотрел?
по первому пункту - полностью согласен, сейчас поправлю! по второму - я подробно описал использование JWT в статье "Подробно про JWT" и здесь дал ссылку на нее в одноименном разделе. Мне показалось, этого достаточно. Спасибо большое за отзыв и замечания!
Про то, что алгоритм сложности редиса O(1) я не знал. Сейчас почитал, спасибо. По вашему вопросу: уточните пожалуйста, а с чем мы сравниваем использование JWT?
Я вижу у JWT такие преимущества: 1. JWT универсальны. Вам будет легче проводить интеграцию со сторонними сервисами, если вы будете использовать универсальный формат ключей доступа. 2. У JWT есть payload. Мы можем добавить туда uuid пользователя, uuid клиента, и дополнительно все, что захотим. В любом стеке для них есть библиотеки, которые предлагают набор параметров для валидации и сами проводят ее. Если мы будем хранить ту же информацию, скажем, в редисе, нам придется самостоятельно писать код валидации. 3. Тому, кто придет работать с тем же кодом после нас, придется разбираться в логике валидации вмето того, чтобы использовать стандартные методы библиотек. 4. У библиотек, как правило, есть нормальная документация, где можно посмотреть зачем нужен каждый параметр.
Но, опять же, нужно понимать, с чем мы сравниваем JWT.
Если коротко - я не знаю. Насколько я понимаю, этот вид токенов используется в OpenId - протоколе, работающем поверх протокола OAuth2. Там архитектура значительно сложнее, чем описанная мной тут. Спасибо за вопрос, буду разбираться!
Абсолютно не секьюрно, вы правы! я отредактирую это место. Сам я всегда передаю токены от сервера клинету в теле запроса, а от ключента к серверу через заглоовок Authorization. Пример с куками привел только для полноты картины, поэтому и пропустил это.
Случайно "отклонил" комментарий к статье, извиняюсь. Мне бы хотелось все-таки на него ответить.
Комментарий был такой:
"Как бы хорошо не был зашифрован запрос, при достаточном количестве времени его можно расшифровать. Если запрос, содержащий учетные данные перехвачен злоумышленником, у него будет много времени на расшифровку."
JWT токен не шифруется, а подписывается. Все что он содержит можно просто просмотреть декодировав текст из base64. Атака может быть, только на получение приватного ключа шифрования, если он слабый, для дальнейшей подмены токенов. —
Мой ответ: Здесь сравнивалась пересылка данных в зашифрованном запросе (например, по протоколу tls). Обсуждаемая атака предполагалась на ключ шифрования запроса, а не на приватный ключ токена. Поскольку подбор ключей шифрования — трудоемкая операция, занимающая много времени, к моменту подбора ключа токен уже устареет и будет бесполезен, а вот пароль — нет. Отсюда я сделал вывод, что пересылка токенов безопаснее, чем пересылка паролей. Согласен, формулировка мутная, нужно перефразировать, спасибо.
хороший вопрос, я об этом не думал. Да, видимо нужно вносить его в black-list при выдаче новой пары
Ок, понял. Ну, тогда в комбинации с редисом я разницы особой не вижу. Это просто альтернативная технология. Может кто-то подскажет?
Спасибо, поправил!
Как я написал в разделе "Структура данных", в рамках моей статьи, email используется в качестве логина. Это отражено в схеме и в тексте раздела.
Проверка уникальности email тут важна потому, что логин должен быть уникальным. Если найдено совпадение, значит пользователь уже регистрировался в приложении раньше.
А в какой схеме это не так? Может я что-то просмотрел?
по первому пункту - полностью согласен, сейчас поправлю!
по второму - я подробно описал использование JWT в статье "Подробно про JWT" и здесь дал ссылку на нее в одноименном разделе. Мне показалось, этого достаточно.
Спасибо большое за отзыв и замечания!
Про то, что алгоритм сложности редиса
O(1)я не знал. Сейчас почитал, спасибо.По вашему вопросу: уточните пожалуйста, а с чем мы сравниваем использование JWT?
Я вижу у JWT такие преимущества:
1. JWT универсальны. Вам будет легче проводить интеграцию со сторонними сервисами, если вы будете использовать универсальный формат ключей доступа.
2. У JWT есть payload. Мы можем добавить туда uuid пользователя, uuid клиента, и дополнительно все, что захотим. В любом стеке для них есть библиотеки, которые предлагают набор параметров для валидации и сами проводят ее. Если мы будем хранить ту же информацию, скажем, в редисе, нам придется самостоятельно писать код валидации.
3. Тому, кто придет работать с тем же кодом после нас, придется разбираться в логике валидации вмето того, чтобы использовать стандартные методы библиотек.
4. У библиотек, как правило, есть нормальная документация, где можно посмотреть зачем нужен каждый параметр.
Но, опять же, нужно понимать, с чем мы сравниваем JWT.
Если коротко - я не знаю. Насколько я понимаю, этот вид токенов используется в OpenId - протоколе, работающем поверх протокола OAuth2. Там архитектура значительно сложнее, чем описанная мной тут. Спасибо за вопрос, буду разбираться!
Абсолютно не секьюрно, вы правы! я отредактирую это место. Сам я всегда передаю токены от сервера клинету в теле запроса, а от ключента к серверу через заглоовок Authorization. Пример с куками привел только для полноты картины, поэтому и пропустил это.
Случайно "отклонил" комментарий к статье, извиняюсь. Мне бы хотелось все-таки на него ответить.
Комментарий был такой:
JWT токен не шифруется, а подписывается. Все что он содержит можно просто просмотреть декодировав текст из base64. Атака может быть, только на получение приватного ключа шифрования, если он слабый, для дальнейшей подмены токенов. —
Мой ответ:
Здесь сравнивалась пересылка данных в зашифрованном запросе (например, по протоколу tls). Обсуждаемая атака предполагалась на ключ шифрования запроса, а не на приватный ключ токена. Поскольку подбор ключей шифрования — трудоемкая операция, занимающая много времени, к моменту подбора ключа токен уже устареет и будет бесполезен, а вот пароль — нет. Отсюда я сделал вывод, что пересылка токенов безопаснее, чем пересылка паролей. Согласен, формулировка мутная, нужно перефразировать, спасибо.