Comments 8
Отличная статья получилась. От себя отмечу пару моментов:
- В статье явно говорится о хэшировании паролей, но в тексте прямо написано "шифрование". Уверен, автор понимает, в чем разница и что именно хэширование применяется для паролей по причине невозможности восстановления исходной строки, это безопаснее.
- не лишним было бы вкратце упомянуть, для чего нужны токены, которые Auth сервис как провайдер авторизации возвращает. Хотя бы то, что этими токенами потом сопровождается каждый запрос в авторизованной зоне приложения, в свою очередь по содержимому токена приложение определяет, что токен не истек и выдан тому же клиенту, который вызывает эндпоинт в авторизованной зоне
по первому пункту - полностью согласен, сейчас поправлю!
по второму - я подробно описал использование JWT в статье "Подробно про JWT" и здесь дал ссылку на нее в одноименном разделе. Мне показалось, этого достаточно.
Спасибо большое за отзыв и замечания!
ввод данных пользователя, проверка уникальности email - и зачем тут "проверка уникальности email"? Или "только email" в вашей технологии может служить идентификатором (логином) пользователя? По вашей же схеме это не так.... В чем необходимость уникальности e-mail при регистрации?
Как я написал в разделе "Структура данных", в рамках моей статьи, email используется в качестве логина. Это отражено в схеме и в тексте раздела.
Проверка уникальности email тут важна потому, что логин должен быть уникальным. Если найдено совпадение, значит пользователь уже регистрировался в приложении раньше.
А в какой схеме это не так? Может я что-то просмотрел?
Статья отличная в качестве шпаргалки, чтобы люди понимали, что же там происходит внутри.
Однако, я считаю, что очень многие переоценивают свои силы и знания в области безопасности, особенно, учитывая, что в этой области постоянно возникают новые угрозы.
Чтобы написать что-то стоящее и по-настоящему безопасное в области аутентификации, нужно только этим и заниматься, постоянно держать руку на пульсе новых угроз.
Если у компании есть такая возможность, то можно попробовать, учитывая, что настоящих специалистов не так уж и много, они стоят дорого, и есть шанс нарваться на человека, переоценивающего свою квалификацию. Моё личное мнение: лучше использовать проверенные решения от разработчиков, которые вот именно, что постоянно только этим и занимаются.
Спасибо большое за статью! Она в паре с предыдущей по JWT позволит переосмыслить процесс авторизации пользователей в моих приложениях.
Из недочётов увидел только одну несущественную "опечатку": Раздел про повторную отправку кода начинается со слов "Регистрация через google, что тут происходит"
email используется, как логин только по одной причине — уникальность.
Как email, так и номер телефона уникальны только в конкретный момент времени. А так, что домены, что телефоны вполне могут менять своих "владельцев". Поэтому жёстко завязываться на email как на уникальный идентификатор мне кажется не очень корректным.
Не так давно я переносил свою почту с .net домена на .ru, ну и менял емейлы во всех своих регистрациях. Так некоторые сервисы, оказывается, не предусматривают возможноть смены логина-почты... Что наши, что зарубежные. Где-то менял через поддержку, а кто-то (тот же СОГАЗ) предлагает только завести новую учётку
Auth service без библиотек