Comments 29
Для начала разберём различие между аутентификацией и авторизацией.
А чем они (оба этих понятия) отличаются от идентификации?
Не знаю, правильно ли я понимаю, но примерно так:
На машине висит номер, это идентификация
ГАИ проверяет по своей базе, что этот номер висит на машине с определённым VIN. Это аутентификация
ГАИ проверяет наличие действующих прав и страховки у водителя машины, это авторизация
ГАИ проверяет по своей базе
Не очень понятна разница между 1 и 2 пунктами.
Вы можете повесить себе чужой номер. Вас идентифицируют как другого
А вот аутентификацию уже не пройдёте
Вы можете повесить себе чужой номер. Вас идентифицируют как другого
А вот аутентификацию уже не пройдёте
См. фильм «ТАСС уполномочен сообщить...» (для справки, конечно :)
Существует вполне реальная практика использования одинаковых автономеров на разных машинах (и вполне законная) — для проведения ОРМ.
Идентификация - способ указать о какой сущности речь. ID-шка, присвоенная юзеру, идентифицирует этого юзера.
Аутентификация - способ проверки/определения идентификации некоей сущности. Логин плюс пароль юзера позволяют определить его ID. Или ID плюс пароль позволяют проверить что юзер действительно имеет данный ID. Аутентификация без Идентификации бесполезна: если мы как-то проверили что логин и пароль верные, но при этом всё ещё не знаем чьи они, то толку с этой проверки мало.
Авторизация - как и описано в статье, проверка прав доступа некоей сущности. Авторизация без Аутентификации бесполезна: мы можем проверить, что юзеру А можно делать Б, но если у нас нет уверенности что Б сейчас пытается сделать именно А, то толку с этой проверки мало.
Ну почему.
Если Дед пришёл домой, и орёт: Бабка, дед пришёл, налей мне самогону.
То Бабка может отказать при авторизации не проводя аутентификацию.
Нет, так это не работает.
Отказ выполнить операцию может быть по самым разным причинам (операция не реализована, сервис перегружен запросами, etc.), так что факт отказа не подразумевает обязательного выполнения авторизации. При авторизации речь идёт о проверке прав доступа, и проверять права только по идентификации без аутентификации нет никакого смысла.
Есть. Ничто не запрещает вам проводить аутентификацию и авторизацию параллельно.
И отказывать в доступе когда придёт только 1 отказ, а не ждать второго.
Я сказал, что нет смысла. И его - нет. Возможность так делать - есть, но смысла в ней - нет.
Делать что-то параллельно имеет смысл для ускорения. Давайте опустим очевидный кейс, когда и аутентификацию и авторизацию выполняет один сервис и тут просто нечего распараллеливать (хотя это довольно частый кейс). Выполнение запросов параллельно подразумевает, что последовательно их делать неприемлемо долго - иначе нет смысла усложнять реализацию параллельными запросами. Но если запрос авторизации выполняется заметное время, значит он использует заметные ресурсы для своего выполнения (напр. лазит в SQL БД). И вот тут получается так, что если мы решим делать этот запрос не дождавшись ответа на проверку аутентификации, то мы открываем возможность DoS-атаки: не аутентифицированные анонимусы из интернетиков могут капитально нагрузить запросами не только наш сервис аутентификации (который обычно пишется с расчётом на это), но и сервис авторизации. В результате - практического смысла параллелить эти запросы всё-таки нет, вреда от этого получится больше, чем пользы.
Выполнение запросов параллельно подразумевает, что последовательно их делать неприемлемо долго - иначе нет смысла усложнять реализацию параллельными запросами.
Снижение времени отклика.
если 200 рабочих дней на 5 авторизаций в день на 2000 человек. Если экономить каждый раз по 10мс, то сэкономим 5 часов рабочего времени за год.
Или вот вам реальный кейс когда авторизация заканчивается до аутентификации.
2х факторная аутентификация. Когда разрешение на VPN подключение проверяется ещё до запроса второго фактора.
https://multifactor.ru/docs/radius-adapter/windows
<!-- Разрешать доступ только пользователям из указанной группы (не проверяется, если удалить настройку) -->
<add key="active-directory-group" value="VPN Users"/>
Если экономить каждый раз по 10мс, то сэкономим 5 часов рабочего времени за год.
Это чушь. На реальной продуктивности сотрудников это не скажется абсолютно никак. А вот создание дыры в виде DoS сервиса авторизации может обойтись довольно дорого.
2FA - да, открывает дополнительные возможности оптимизации. Проверять авторизацию после проверки аутентификации по одному фактору не дожидаясь второго - может считаться достаточно безопасным в плане вышеупомянутой DoS-атаки. Но смысла, реального, в этом всё-равно чаще нет. Аутентификация подразумевает наличие юзера, который что-то делает в UI. 2FA подразумевает дополнительные действия в UI. Скорость работы юзера в UI на несколько порядков меньше скорости ответа сервиса авторизации, так что распараллеливание запроса к нему ничего реально полезного не даст, а реализацию усложнит.
В перспективе использования хардварных ключей для 2FA, не требующих действий юзера в UI - такое распараллеливание поможет нарисовать красивые бенчмарки, но фактический эффект на реальный UX будет всё-равно не заметен. Точнее, скажу иначе. Эффект может быть заметен, если сервис авторизации заметно тормозит. Но в таком случае намного больший эффект даст его оптимизация, а не распараллеливание запросов на 2FA и авторизацию.
Это чушь. На реальной продуктивности сотрудников это не скажется абсолютно никак.
Цифры не врут. курочка по зёрнышку клюёт.
Но смысла, реального, в этом всё-равно чаще нет.
Да, чаще нет. но мы рассматриваем все случаи.
Аутентификация подразумевает наличие юзера, который что-то делает в UI.
Ага, подключается к VPN.
И в зависимости от авторизации может быть 3 варианта(с точки зрения радиус сервера):
не пущать
пущать
пущать, но только с 2fa
Скорость работы юзера в UI на несколько порядков меньше скорости ответа сервиса авторизации
нет, сопоставима. аутентификация первого фактора+ авторизация+ отправка пуша через интернет занимает несколько секунд. В случае с SMS может быть ещё дольше... особенно если SMS за границу.
В перспективе использования хардварных ключей для 2FA, не требующих действий юзера в UI
Это уже не 2fa... и есть у меня trezor model t. Продвинутей некуда. С поддержкой тухло.
отправка пуша через интернет занимает несколько секунд
Ну вот и я об этом же. Проверять авторизацию параллельно с первым фактором (паролем) опасно (открываем DoS), а параллельно со вторым (SMS etc.) нет смысла (второй занимает столько времени, что на этом фоне задержка на запрос авторизации просто теряется).
Это уже не 2fa
Почему это? Первый фактор - знание (пароля), второй - владение (USB-ключом/телефоном). Фактор владения может проверяться автоматически, не требуя действий юзера (ключ в USB юзер мог вставить заранее), но он не перестаёт от этого быть 2FA.
мы рассматриваем все случаи
Ну, если все-все, то можно придумать очень искусственный кейс, когда юзер находится в локалке где и все сервисы (типа, работает в офисе с сервисами своей компании), пароль ему браузер заполняет автоматом и так же автоматом отправляет форму логина, второй фактор это USB-ключ не требующий нажатия кнопок для подтверждения, и при этом сервис авторизации отвечает с задержкой, заметной юзеру невооружённым глазом (от 100ms). Вот в таких условиях распараллеливание запроса на второй фактор аутентификации и на авторизацию может дать заметный эффект в UX. Но, опять же, на мой взгляд и тут намного больше пользы будет от оптимизации скорости ответа сервиса авторизации, нежели от распараллеливания.
Ну вот и я об этом же. Проверять авторизацию параллельно с первым фактором (паролем) опасно (открываем DoS), а параллельно со вторым (SMS etc.) нет смысла (второй занимает столько времени, что на этом фоне задержка на запрос авторизации просто теряется).
Нам важна абсолютная, а не относительная задержка. Относительную просто заметить легче, а то что она не заметна на глаз ничего не значит.
Почему это? Первый фактор - знание (пароля), второй - владение (USB-ключом/телефоном).
В перспективе использования хардварных ключей для 2FA, не требующих действий юзера в UI
Как будет вводится пароль без действия пользователя в UI?
Ну, если все-все, то можно придумать очень искусственный кейс
Я вам привёл реальный пример. Буквально вчера этим занимался
Нам важна абсолютная, а не относительная задержка. Относительную просто заметить легче, а то что она не заметна на глаз ничего не значит.
Если на глаз юзер задержку не замечает - зачем тратить время разработчиков и усложнять код для оптимизации? Просто чтобы разработчики развлеклись за счёт бизнеса?
Как будет вводится пароль без действия пользователя в UI?
Браузеры/плагины давно умеют автозаполнять пароли и даже автоматом отправлять форму.
Если на глаз юзер задержку не замечает - зачем тратить время разработчиков и усложнять код для оптимизации?
Если юзер не замечает задержку на глаз, это не значит что в масштабах компании эта задержка не преобразуется в значимую величину.
и даже автоматом отправлять форму.
Вот такого я пока не видел.
в масштабах компании эта задержка не преобразуется в значимую величину
Эта величина же не в вакууме существует. Да, абсолютная цифра, особенно если посчитать за большой период времени (год), может быть впечатляющей. Но практического эффекта на бизнес она оказывать не будет никакого. А вот затраты времени на разработку и поддержку этой оптимизации - как правило оказываются в разы больше, чем казалось при планировании этой "фичи". Иными словами: бизнесу такие оптимизации чаще вредят, нежели помогают. И "чаще" тут практически эвфемизм, потому что я лично считаю что здесь "чаще==99.999%", но это моё личное мнение которое я не могу подкрепить статистикой, так что приходится формулировать осторожно. :)
Если Дед пришёл домой, и орёт: Бабка, дед пришёл, налей мне самогону.
Дед таки прошел у бабки аутентификацию по фейсу.
Но в авторизации ему было отказано :)
нет, бабка отказала даже не смотря на фейс. Она не знает точно кто крикнул.
А вот авторизацию он прошёл (деду пить нельзя)
нет, бабка отказала даже не смотря на фейс.нет, бабка отказала даже не смотря на фейс.
Так аутентификацию он точно прошел, иначе бы бабка вызвала полицию :)
Собственно, и авторизацию он тоже прошел, просто его права доступа были изменены в связи со скорректированной бабкой политикой :)
зачем бабке вызывать полицию, если оне не знает о факте подлога? или она должна полицию вызывать на любой шорох из-за сарая, когда не знает кто там шарится?
Логин плюс пароль юзера позволяют определить его ID.
Точнее, наверное, так: логин и пароль сущности переменные, поменять их можно только в путь. А ID — вещь постоянная.
И определение по текущему логину и паролю конкретного ID — это уже аутентификация.
А с определением что есть идентификация — есть проблемы.
Возможно, как вариант — идентификация это процесс присвоения чему-то (например, учетной записи) конкретного ID.
(с авторизацией вопросов нет)
ID тоже может меняться. И у одной сущности может быть больше одного ID. Примеры из жизни - обычный паспорт и загран, плюс возможность изменить имя/фамилию в паспорте по желанию. Но во всех этих случаях некий ID позволяет идентифицировать конкретную сущность, хоть и не обязательно этот ID вечен и не обязательно он единственный.
обычный паспорт и загран,
Я не в курсе — у вас в стране есть такое понятие как «идентификационный код», который должен получить каждый гражданин страны и без которого никуда?
(без паспорта — можно, без кода — нельзя :)
А паспорта, как и имя с фамилией — это все тот же логин и пароль :)
(можно потерять и получить новый)
Эволюция облачной системы авторизации