Приходилось ли Вам когда-нибудь тестировать формы авторизации?
Думаю, что каждый тестировщик сталкивался с ситуацией, когда после тестирования одной из таких «форм» с логином и паролем приходилось заводить баг-репорт c использованием слова «Авторизация».
Но ведь задача тестировщика постараться максимально точно и грамотно обозначить проблему!
Возможно ли это? Конечно!
Именно поэтому в данной статье мы разберем такой процесс как «Авторизация», а также поговорим о таких очень близких понятиях как «Идентификация» и «Аутентификация». Разберем, как всё это взаимосвязано и постараемся сделать это максимально просто и доступно для того, чтобы у вас не осталось никаких вопросов после прочтения данной статьи!
Итак, для наглядности и лучшего понимания были подготовлены три экрана мобильного телефона c типичной формой логина в приложениях:
· первый экран (Screen 1) как наглядный пример процесса «Идентификации»;
· второй экран (Screen 2) как наглядный пример процесса «Аутентификации»;
· третий экран (Screen 3) как наглядный пример процесса «Авторизации».
Итак, Screen 1 - на первом экране идет распознавание пользователя по его уникальному идентификатору.
Цель идентификации – понять, кто “стучится в нашу систему”. Чаще всего для идентификации используются: имейл, имя пользователя, телефон…
Бывает возможность выбора. К примеру, залогиниться по имени пользователя или по номеру телефона. Важно то, что этот идентификатор будет являться уникальным значением. В Базе Данных это, вероятнее всего, будет столбец в таблице с уникальными данными (primary key). То есть в системе не может быть зарегистрировано два одинаковых идентификатора, два одинаковых номера телефона, два одинаковых имейла и так далее.
Например, при попытке зарегистрировать новый адрес электронной почты пользователь вводит свой идентификатор (логин), например: «Вася92», а система подсвечивает поле красным и сообщает, что такой пользователь уже зарегистрирован в системе, предлагая на выбор несколько других вариантов – именно это и будет пример идентификации.
Screen 2 - процесс аутентификации, а именно проверки пользователя на его подлинность, что юзер у нас действительно является тем, кем он представляется системе, пытаясь в нее попасть.
Существует 3 фактора, которые напрямую задействуются в процессе аутентификации:
1. Известность
Например пароль, ПИН-код, секретное слово и так далее...
Главное, что эта информация известна конкретному пользователю.
2. Обладание
Второй фактор – это обладание, является ли пользователь (который “стучится в систему”) обладателем чего-то, к примеру – уникальных биометрических данных, присущих только ему.
Это очень хорошо распространено в телефонах, к примеру, когда девайс распознает владельца по отпечатку пальца.
3. Признак
Пользователь имеет какой-то уникальный признак, и система его может аутентифицировать и пропустить дальше. К примеру: в случае использования мобильного банкинга или налогового приложения после его запуска система попросит у пользователя набор ключей. Пользователь использует флешку с электронными ключами, система распознает эти ключи, а затем выдает пользователю доступ к использованию системы.
Обратите внимание! Если доступ к системе предоставляется после введения логина и пароля, то это будет однофакторная аутентификация - самая простая.
Но если система говорит пользователю: «Окей, тебе известен пароль, но возможно ты его украл. Какими-то биометрическими данными ты еще обладаешь? Давай-ка ты, дружочек-пирожочек, покажи свое лицо и докажи системе повторно - что ты есть ты!”, в таком случае система проведет повторную аутентификацию и вот это уже будет наша многофакторная, а конкретнее двухфакторная аутентификация (ДФА, 2FA).
Screen 3 - это завершающий этап, когда:
· система проверила наш идентификатор;
· успешно прошел процесс аутентификации.
После чего следует наделение пользователя определенными правами. Возможно, система авторизовала нас как юзера с уже определенным набором возможностей и показывает нам информацию, который должен видеть обычный пользователь системы.
На 3-м экране мы видим определенные секции в нашем приложении. Представим, что мы можем кликнуть по ним и увидеть информацию, к примеру: кликнуть по иконкам и просмотреть, что там внутри, прокрутить страницу и так далее…
В данном случае мы зашли в систему как обычный пользователь, но ведь система могла авторизовать нас как администратора. Во втором случае система предоставила право, к примеру, на редактирование или удаление информации. С точки зрения тестирования у пользователя появляется просто огромное поле возможностей для проведения тестирования.
Это крайне важно с точки зрения безопасности – на сколько система правильно ведет себя на этапе идентификации, затем на этапе аутентификации и в итоге авторизации.
Тестировщик проверяет, все ли происходит в соответствии с требованиями, нет ли каких-то ошибок, потому что баги на этапах идентификации/аутентификации/авторизации могут быть критичны.
Таким образом, мы разобрали понятия идентификации, аутентификации и авторизации. Надеемся, если раньше у вас возникали какие-то трудности с этим, то теперь все стало более понятно.
