Всем привет, дорогие друзья!

Приходилось ли Вам когда-нибудь тестировать формы авторизации?

Думаю, что каждый тестировщик сталкивался с ситуацией, когда после тестирования одной из таких «форм» с логином и паролем приходилось заводить баг-репорт c использованием слова «Авторизация».

Но ведь задача тестировщика постараться максимально точно и грамотно обозначить проблему!

Возможно ли это? Конечно!

Именно поэтому в данной статье мы разберем такой процесс как «Авторизация», а также поговорим о таких очень близких понятиях как «Идентификация» и «Аутентификация». Разберем, как всё это взаимосвязано и постараемся сделать это максимально просто и доступно для того, чтобы у вас не осталось никаких вопросов после прочтения данной статьи! 

Итак, для наглядности и лучшего понимания были подготовлены три экрана мобильного телефона c типичной формой логина в приложениях: 

·        первый экран (Screen 1) как наглядный пример процесса «Идентификации»;        

·        второй экран (Screen 2) как наглядный пример процесса «Аутентификации»;

·        третий экран (Screen 3) как наглядный пример процесса «Авторизации».

Итак, Screen 1 - на первом экране идет распознавание пользователя по его уникальному идентификатору.

Цель идентификации – понять, кто “стучится в нашу систему”. Чаще всего для идентификации используются: имейл, имя пользователя, телефон…

Бывает возможность выбора. К примеру, залогиниться по имени пользователя или по номеру телефона. Важно то, что этот идентификатор будет являться уникальным значением. В Базе Данных это, вероятнее всего, будет столбец в таблице с уникальными данными (primary key). То есть в системе не может быть зарегистрировано два одинаковых идентификатора, два одинаковых номера телефона, два одинаковых имейла и так далее.

Например, при попытке зарегистрировать новый адрес электронной почты пользователь вводит свой идентификатор (логин), например: «Вася92», а система подсвечивает поле красным и сообщает, что такой пользователь уже зарегистрирован в системе, предлагая на выбор несколько других вариантов – именно это и будет пример идентификации.

Screen2 - процесс аутентификации, а именно проверки пользователя на его подлинность, что юзер у нас действительно является тем, кем он представляется системе, пытаясь в нее попасть.

Существует 3 фактора, которые напрямую задействуются в процессе аутентификации:

1.      Знание

Например пароль, ПИН-код, секретное слово и так далее...

Главное, что эта информация известна конкретному пользователю. 

2.      Владение

Второй фактор – это владение, является ли пользователь (который “стучится в систему”) обладателем чего-то, к примеру – уникальных биометрических данных, присущих только ему.

Это очень хорошо распространено в телефонах, к примеру, когда девайс распознает владельца по отпечатку пальца. 

3.      Свойство

Пользователь имеет какой-то уникальный признак, и система его может аутентифицировать и пропустить дальше. К примеру: в случае использования мобильного банкинга или налогового приложения после его запуска система попросит у пользователя набор ключей. Пользователь использует флешку с электронными ключами, система распознает эти ключи, а затем выдает пользователю доступ к использованию системы. 

Обратите внимание! Если доступ к системе предоставляется после введения логина и пароля, то это будет однофакторная аутентификация - самая простая.

Но если система говорит пользователю: «Окей, тебе известен пароль, но возможно ты его украл. Какими-то биометрическими данными ты еще обладаешь? Давай-ка ты, дружочек-пирожочек, покажи свое лицо и докажи системе повторно - что ты есть ты!”, в таком случае система проведет повторную аутентификацию и вот это уже будет наша многофакторная, а конкретнее двухфакторная аутентификация (ДФА, 2FA).

 Screen 3 - это завершающий этап, когда:

·         система проверила наш идентификатор;

·         успешно прошел процесс аутентификации.

После чего следует наделение пользователя определенными правами. Возможно, система авторизовала нас как юзера с уже определенным набором возможностей и показывает нам информацию, который должен видеть обычный пользователь системы.

На 3-м экране мы видим определенные секции в нашем приложении. Представим, что мы можем кликнуть по ним и увидеть информацию, к примеру: кликнуть по иконкам и просмотреть, что там внутри, прокрутить страницу и так далее…

 В данном случае мы зашли в систему как обычный пользователь, но ведь система могла авторизовать нас как администратора. Во втором случае система предоставила право, к примеру, на редактирование или удаление информации. С точки зрения тестирования у пользователя появляется просто огромное поле возможностей для проведения тестирования.

Это крайне важно с точки зрения безопасности – на сколько система правильно ведет себя на этапе идентификации, затем на этапе аутентификации и в итоге авторизации.

Тестировщик проверяет, все ли происходит в соответствии с требованиями, нет ли каких-то ошибок, потому что баги на этапах идентификации/аутентификации/авторизации могут быть критичны.  

Таким образом, мы разобрали понятия идентификации, аутентификации и авторизации. Надеемся, если раньше у вас возникали какие-то трудности с этим, то теперь все стало более понятно.

Спасибо за внимание!