Представьте, что аутентификация — это ключ от дома, а авторизация — список комнат, в которые этот ключ открывает дверь. В современных приложениях простой ключ-пароль заменяется сложными системами: токенами, OAuth 2.0 и OIDC.

Я, Екатерина, QA Lead в «Лиге Ставок», покажу, как с помощью инструментов тестирования проводить базовые проверки: тестировать валидность токенов, отслеживать их обновление и проверять корректность прав доступа.

Это руководство из трех частей поможет систематизировать знания и применять их в работе — от основ до реальных кейсов.

Часть 1: Эволюция аутентификации

От Basic Auth к токенам: как развивались методы проверки подлинности и почему простой авторизации стало недостаточно.

Часть 2: Современные стандарты

Single Sign-On (SSO), OAuth 2.0, форматы токенов — разбираем основные протоколы и механизмы авторизации.

Часть 3: Практика для QA

Реальные примеры тестирования: инструменты и методы для базовые проверки безопасности аутентификации и авторизации.

Для начала разберем, в чем отличие и смысл следующих понятий: 

• Идентификация — вы вводите логин (сообщаете, кто вы). В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, итд.

• Аутентификация — вы вводите пароль или код из SMS (доказываете, что это вы).

• Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.

Рассмотрим жизненный пример поездки на самолете:

• Идентификация: Вы предъявляете посадочный талон на стойке регистрации. Ваше имя и номер рейса — это ваша "учётная запись".

• Аутентификация: Вы показываете паспорт, чтобы сотрудник авиакомпании убедился, что посадочный талон принадлежит именно вам.

• Авторизация: Вас пропускают в зону выхода на посадку (гейт) и разрешают сесть в самолёт, потому что ваше имя есть в списке пассажиров этого рейса. При этом доступ в бизнес-салон или в кабину пилотов вам не авторизован.

Краткая суть:

• Идентификация: "Я — Василий Пупкин."

• Аутентификация: "Вот мой паспорт, доказывающий, что я — это Василий Пупкин."

• Авторизация: "Василию Пупкину разрешён полет на самолете"

Представь, как это работает, например, в «Лиге Ставок»:

1. Идентификация («Найди меня»): Ты говоришь системе, кто ты — вводишь свой номер телефона или почту. Она по этим данным находит твой аккаунт. Сюда же относится и первичная идентификация в ЦУПИС, где система впервые узнаёт, что ты вообще существуешь.

2. Аутентификация («Докажи это»): Система просит тебя доказать, что это действительно твой аккаунт. Ты вводишь пароль — это и есть твоё доказательство.

3. Авторизация («Что мне можно?»): После того как ты доказал свою личность, система смотрит: «Ага, это Василий. Он обычный пользователь». И на основе этого решает, пускать ли его в личный кабинет, на страницу с матчами или в раздел с поддержкой.

Виды аутентификации и авторизации

Аутентификация по токенам:

• Single Sign-On (SSO)

• OIDC

• Simple Web Token (SWT)

• JSON Web Token (JWT)

• OAuth 2.0

• HTTP authentication

Basic

Basic — это простейший способ передачи учетных данных, при котором логин и пароль пользователя объединяются в одну строку, кодируются в формат base64 и отправляются в заголовке HTTP-запроса. Поскольку данные не шифруются, в чистом HTTP этот метод крайне небезопасен и позволяет легко перехватить пароль. Однако при использовании защищенного протокола HTTPS, который обеспечивает сквозное шифрование всего соединения, передача становится безопасной, так как данные передаются внутри зашифрованного канала.

Алгоритм:

1. Первоначальный запрос — Браузер обращается к защищенному ресурсу без аутентификации

2. Требование аутентификации — Сервер возвращает статус 401 с заголовком WWW‑Authenticate, указывая схему Basic и область доступа

3. Ввод учетных данных — Браузер показывает диалог ввода, пользователь вводит логин/пароль

4. Автоматическая аутентификация — Браузер добавляет заголовок Authorization с base64-кодированными данными во все последующие запросы

5. Проверка доступа — Сервер аутентифицирует пользователя (проверяет учетные данные) и авторизует (определяет права доступа)

Беспрепятственный доступ - После успешной аутентификации пользователь получает доступ к ресурсам без повторного ввода данных

Ключевые особенности Basic Auth:

• ✅ Простота реализации

• ✅ Широкая поддержка во всех языках и фреймворках

• ❌ Требует HTTPS (данные передаются в base64, что легко декодируется)

• ❌ Нет встроенного механизма для выхода (logout)

• ❌ Токен передаётся в каждом запросе

Эта схема отлично подходит для внутренних API или простых систем, но для публичных сервисов лучше использовать более безопасные методы (OAuth, JWT).

Пример: рассмотрим на некотором хосте example.com

Host: example.com

Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

Результат, после декодирования: Basic = Логин + ":" + Пароль = aladdin:opensesame

Это и есть заголовок Authorization с base64-кодированными данными, которые передаются во все последующие запросы

Для декодирования:https://www.base64decode.org/ru

Bearer

Bearer — это любые, полученные пользователем от провайдера API, данные, которые при передаче в этот API подтверждают его (пользователя) личность. В большинстве случаев это текстовые токены того или иного формата

На схеме пример авторизации на сайте. После входа в "личный кабинет" при помощи ввода телефона или почты и пароля, вам становится доступна функция генерации токена. Вы нажимаете на кнопку "Войти". Проверка пользователя в базе данных -  получили сгенерированную строку, после чего передаете её в каждом своем запросе к API. Эта строка - Bearer token.

Это метод проверки подлинности пользователя веб-приложения, при котором пользователю отображается HTML-страница для ввода логина и пароля

Session token

Session token — это уникальный временный идентификатор, который присваивается пользователю во время процесса входа на веб-сайт или в приложении

Алгоритм: 

1. Запрос страницы авторизации

   a. Пользователь запрашивает страницу входа через браузер
   b. Сервер возвращает HTML-форму для ввода учетных данных

2. Проверка учетных данных

   a. Пользователь вводит логин и пароль в форму
   b. Клиент отправляет данные на сервер методом POST
   c. Сервер проверяет корректность логина и пароля

3. Создание сессии

   a. При успешной проверке сервер создает новую сессию
   b. Генерируется уникальный идентификатор сессии (session token)
   c. Сервер отправляет токен в заголовке Set-Cookie

4. Автоматическая аутентификация

   a. Браузер автоматически сохраняет cookie с токеном
   b. Все последующие запросы к серверу включают этот токен
   c. Сервер проверяет токен и извлекает данные сессии для идентификации пользователя

5. Доступ к защищенным ресурсам

   a. Сервер использует информацию из сессии для предоставления персонализированного контента
   b. Пользователь получает доступ к защищенным страницам без повторного ввода пароля

Приложение может создать session token двумя способами:

1. Запись в памяти или БД, содержащая данные пользователя для авторизации.. Сессия должна содержать всю необходимую информацию о пользователе для возможности авторизации его запросов.

2. Зашифрованный/подписанный объект, который сам несет в себе данные пользователя и срок действия.

Отличие session и bearer token: сессия передается в каждом запросе и при этом хранится на сервере или бд, поэтому каждый запрос = поход на сервер; bearer token - не требует хранения состояния на сервере, что упрощает масштабирование и распределение нагрузки

Замечание

Необходимо понимать, что перехват session token зачастую дает аналогичный уровень доступа, что и знание username/password. Поэтому все коммуникации между клиентом и сервером в случае forms authentication должны производиться только по защищенному соединению HTTPS.

CA - это ваше цифровое удостоверение, которое выдает доверенная организация. Оно подтверждает вашу личность в сети, а ваш секретный ключ служит паролем, который доказывает, что это удостоверение именно ваше.. Также сертификат криптографически связан с закрытым ключом, который хранится у владельца сертификата и позволяет однозначно подтвердить факт владения сертификатом.

Во время аутентификации сервер выполняет проверку сертификата на основании следующих правил:

1. Проверка подлинности издателя: Сертификат должен быть подписан доверенным Удостоверяющим Центром (УЦ). Это гарантирует, что документ выдан законной организацией.

2. Проверка срока действия: Сертификат должен быть действующим, то есть текущая дата должна находиться в пределах срока его годности.

Проверка на отзыв: Сертификат не должен быть досрочно отозван своим Удостоверяющим Центром. Это проверяется по специальным спискам отозванных сертификатов.

После аутентификации приложение может выполнить авторизацию запроса на основании сертификата,  где есть как subject (имя владельца), issuer (эмитент), serial number (серийный номер сертификата) или thumbprint (отпечаток открытого ключа сертификата)

Разберем пример реальной жизни для более легкого понимания

1. Вы (Клиент) → приходите в университет и просите сделать пропуск

2. Администрация (Удостоверяющий Центр) → проверяет ваши документы (паспорт, документы о зачислении), фотографирует вас и изготавливает пропуск с вашей фотографией, именем и печатью

3. Вы → получаете пропуск и теперь можете использовать его для входа в разные здания

4. Охранник (Веб-приложение) → когда вы подходите к двери, смотрит на ваш пропуск, проверяет печать университета и сравнивает фото с вашим лицом

5. Доступ разрешен! ✅

? Аналогия с цифровыми сертификатами:

Сертификат — это цифровой паспорт для сайтов, который:

• Выдает доверенная организация (как паспортный стол)

• Подтверждает "личность" сайта (что это действительно ваш банк, а не мошенник)

• Позволяет установить безопасное соединение (закрытое от посторонних)

Two-factor authentication (2FA)

Одноразовые пароли используются как дополнительная защита вместе с основным паролем. Это называется двухфакторной аутентификацией (2FA). Для входа нужно подтвердить две вещи:

1. Что ты знаешь — свой постоянный пароль.

2. Что у тебя есть — твой телефон или специальное устройство, которое генерирует этот одноразовый код.

Такой подход сильно повышает безопасность. В этой концепции необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей).

Источники для создания одноразовых паролей:

1. Специальные приложения или устройства (токены). Например, Google Authenticator или банковская ключ-таблетка. Они на основе общего с сайтом секрета и текущего времени генерируют новый код каждые 30 секунд. Сервер знает этот секрет и может проверить ваш код.

2. СМС-сообщение. Код приходит на ваш телефон. В этом случае фактором владения является сам ваш номер телефона и SIM-карта.

3. Лист с кодами. Это распечатанный список одноразовых паролей. Вы просто используете их по очереди, каждый для одного входа.

4. Требуется ввести новый одноразовый пароль с указанным номером.

Access key, API key

Способ для программ и сервисов обращаться к API без пароля пользователя. Используется длинный уникальный ключ, который легко отозвать в случае утечки, не затрагивая основную учётную запись. Более безопасен и удобен для автоматизации, чем пароли.

Ключи имеют высокую энтропию, что делает их устойчивыми к подбору. Компрометация ключа не затрагивает основную учётную запись пользователя. Достаточно отозвать старый ключ и выпустить новый.