Comments 23
есть вариант когда регистрация происходит в ручном режиме - оператор (администратор портала) вводит телефон и права/роли для юзера (такое для корпоративного применения). юзер при входе на портал видит код. вводит этот код в телеге и на странице и вместо кода открывается его станица (ы). регистрация в телеграмм боте произойдет если юзера внесли в базу портала. удобство - не надо ничего помнить.
Это же асбстрактный пример который в реальном бизнесе мало применим.
Имхо самый простой вариант входа по номеру телефона как это сделано у Озона / Wiildberies.
Кажется это единственный правильный вариант который может использоваться на порталах, которые не предназначены для непредённого круга лиц и ботов
Если не брать высосанный из пальца "портал" с десятком клиентов из комментария выше, а говорить про индустрию в целом, то "простым" этот вариант является только для ритейла. Который с одной покупки отобьёт 100 смс. Но сайтам, которые ничего не продают пользователям, авторизация по смс выходит слишком дорого.
Так что реально самым простым вариантом все равно остается старая добрая авторизация по паролю.
корпоративных порталов не так много, хотя кто их считал , с их закрытым доступом... но применение бота не заканчивается только на входе в портал, этот же бот может открывать и вход по RDP для конкретного ip данного юзера. и ещё - использование логина/пароля и/или телефона вызывает ввод этих логинов/паролей/телефонов/мыл, что не всегда есть хорошо. при использовании бота ничего такого вводить на странице браузера не нужно, просто увидеть 3-значное число и ввести его в боте. всё в открытую. и не надо никому писать -"ни кому не сообщайте это число".
ну не нравится такой вариант - не используй. Есть такое, работающее - почему бы не поделиться?
Теперь уже когда вы попытаетесь зайти в свой аккаунт сервер вернет ошибку, т.к уже ваш Refresh Token не валидный
А как проверяется валидность нового и старого refresh токена? По времени его создания? Если да, то быть авторизированным в системе может быть только 1 устройство пользователя?
Если мы хотим одновременно быть онлайн с разных устройств, то можно иметь некий белый список устройств с которых можно авторизироваться. И чтобы добавить устройство в этот список, нужно подтвердить что вы имеете доступ к устройству с которого первый раз создавали профиль
Да, с этим знаком, но что если у злоумышленника получиться скомпрометировать идентификатор устройство пользователя, так же можно обновлять refresh токен только тот, который должен быть обновлен, но для этого надо уже начинать хранить refresh токена в бд? (тогда пропадает весь смысл удобства jwt авторизации?)
Здесь наверное основной вопрос в том как уникально идентифицировать пользователя. Если злоумышленник сможет каким то образом достать и токены и подменить id устройства или еще что-то (например если мы добавим проверку по ip), то здесь затрудняюсь ответить, т.к а чем в действительности я как настоящий пользователь отличаюсь от злоумышленника (который теперь по сути имеет все что есть у меня). Здесь наверное нужно поиграться с временем протухания токенов.
На счет хранения токена в БД. А какой смысл ? Если токен воруют, то если его потом поменяют, то он просто не пройдет валидацию по сигнатуре
На счет хранения токена в БД
Чтобы сохранялась аутентификация других устройств и тем самым разделения токена снижает саму нагрузку на refresh, ибо хранить IP или тот же id девайса приводит порой к неудобству при использовании или бессмысленному накручиванию защиты, когда этого не требуется, а в бд он храниться как единственный refresh токен для такого устройства
Какая-то очень странная стена текста.
С одной стороны я могу допустить наличие аудитории, которой надо рассказывать на уровне "база данных — это такой понарошку текстовый файлик". Хотя смотрится это несколько странно.
С другой — я не понимаю, зачем откровенно врать про технологии, которые вы не используете. Вполне достаточно описать их объективные недостатки. Зачем выдумывать еще какие-то из головы?
Таким образом, в такой модели авторизации web-приложение будет каждый раз обмениваться логином и паролем с сервером при необходимости, а это опасность перехвата. В дополнении к этому логин и пароль придется где-то хранить
Что за чушь вы здесь пишете? Это описание подходит только про basic авторизацию, но во-первых, тогда именно так и надо писать, а не "авторизация с логином и паролем". А во-вторых, программисту "хранить" ничего не нужно, браузер в этом случае все сохранит сам, и, насколько я знаю, из яваскрипта получить доступ к этим данным нельзя.
Плюс чуть ли не половина статьи посвящена ужасам передачи пароля по незщенному соединению. Вы это серьезно? В 2023 году? Про сайт без TLS?
Тем более что по вашему собственному же признанию, без шифрования трафика тот же токен спокойно уплывает. То есть вся с таким трудом построенная защита превращается в тыкву. И при этом про HTTPS в статье ни слова!
Хотя существуют методики и для хищения данных из куки. Здесь нужно запомнить один момент. У вас не получится на 100% защититься от всех атак в браузере, но чем больше уровней защиты вы установите, тем меньше вероятность взлома.
Что вы имеете в виду? HTTPonly? Почему тогда так и не пишете? Какой смысл рекомендовать куки и не описывать способ предохранения от их кражи?
В целом совершенно не раскрыта тема, чем ваш такой продвинутый способ отличается от банальной сессионной куки (спойлер: ничем).
Во-первых, что вы понимаете под логин + пароль.
Во-вторых, про SSL ни слова, т.к статья не про то. А описывать все вообще все аспекты авторизации одной статьи не хватит.
В третьих, лучше объяснить как ребенку, но зато поймут точно все, чем надеется что все супер умные и знающие (зачем читать статью об авторизации, если ты и так знаешь как это делать)
Объяснять, как ребёнку — отдельный, непростой навык. Можно обойти сложные детали стороной, можно опустить какие-то подробности реализации, но ни в коем случае нельзя вводить в заблуждение, допуская ошибки или утверждая об однозначности там, где есть множество вариантов.
Например, refresh token, который, как можно предположить из вашего повествования — тот же JWT. На самом деле нет. Есть понятие opaque token — такие токены не несут информацию сами по себе, но хранятся на сервере, а он, в свою очередь, знает, кому этот токен был выдан, какой срок действия, итд. Как ни странно, но многие стандарты рекомендуют делать refresh именно таким.
Authn/authz действительно сложная тема, когда я в ней разбирался, я прочитал много статей и далеко не все были точны и достаточно высокого качества. Я на тот момент не мог их оценить, поэтому много часов потратил, ломая голову, почему же написано одно, а работает совсем по-другому (или вовсе не работает).
Поэтому я недовольство вашего собеседника хорошо понимаю, а вам бы предложил сузить скоуп статьи (ну, или разбить её на несколько частей), но более тщательно проработать обозреваемые темы.
Слушайте, не спорю что статья не описывает все детали (ровно как и любая статья). Как минимум на практике не встречал статьи, которая отвечала бы на все вопросы.
Второй момент, да мы можем действительно хранить данные о времени жизни ни в самом токене, а в БД, но как вы и сказали это одна из реализаций (более сложная). Статья расчитана на людей, которые эту авторизацию хотят сделать сами у себя. Вот ответьте, если бы у вас были низкие знание о разработке, то какой из видов refresh токена выбрали бы вы?
Это все равно что нанимать команду разработчиков для создания одностраничного сайта булочной (хотя 90% требований можно закрыть конструктором на подобие вордпреса или тильды)
Почему современные приложения не используют логин + пароль для авторизации.
А как вы заходите в гмейл, например?
То что вы при авторизации вводите и логин и пароль это естественно. Здесь вопрос в том какие данные хранить в браузере для последующего взаимодействия. Можно ведь в localstorage сохранить логин и пароль и постоянно их на сервер отправлять. А при авторизации через gmail использется OAuth, который использует токены, а не просто логин и пароль
Скажите, вы правда никогда не слышали про сессионные куки?
Откуда вы это вытащили-то, "хранить в браузере для последующего взаимодействия"? Ведь ни в одном руководстве, ни на одном реальном сайте такая дичь не используется.
В этом свете ваша публикация смотрится еще смешнее. Я думал что вы специально привираете про парольную авторизацию, а вы, похоже, действительно просто не знаете, как она делается.
Я действительно не совсем понимаю что вы имеете ввиду под парольной авторизацией (явно не то что я). Авторизация по логину + паролю, действительно почти (именно почти) нигде не используется. О чем в статье также написано. Тем не менее она использовалась раньше и поэтому нужно упомянуть о ней, чтобы было с чем сравнивать.
Скажите, мы сейчас на сайте habr.com, верно?
И здесь, как и почти везде, авторизация по паролю не используется, правда же?
А gmail, про который вам выше писали, или яндекс, или множество других сервисов существуют, видимо, в какой-то параллельной реальности?
Я действительно не совсем понимаю что вы имеете ввиду под парольной авторизацией
В этом-то и проблема. Вы беретесь о ней судить, но по всему выходит, что никогда в жизни её не делали, и просто не знаете, что это такое.
Я уважаю ваше желание жить в розовом мире и считать, что у нас что ни компания то обязательно Яндекс. Вот только я видел и работал с проектами не только в больших компаниях, но и с теми что приносят заказчики на фрилансе. И именно поэтому я с такой уверенностью вам говорю, что не все компании это Яндекс и не все делают все идеально. И даже не у всех самые новые технологии используются (но тут вы точно не поверите и скажите что я шучу)
У вас с логикой проблемы.
Вам приводят яндекс в качестве сайта, где используется "неправильный", с вашей точки зрения, вариант авторизации — по логину и паролю. А вы начинаете отвечать, что "что не все компании это Яндекс и не все делают все идеально". Вы определитесь сначала — правильно делать авторизацию по паролю, или неправильно.
Но главное, вам надо сначала научиться делать авторизацию по паролю, а потом уже рассуждать о том, как она работает.
Способы создания авторизации на сайте. Руководство с примерами. Безопасность в браузере