Аналитики часто путают понятия аутентификации и авторизации, которые действительно связаны между собой, но отличаются. Чтобы подчеркнуть эту разницу, сегодня я на практическом примере интернет-магазина расскажу про HTTP-ответы и виды аутентификации веб-API, доступные в Postman.
Аутентификация и авторизация: versus или вместе
Чтобы ограничить доступ одного или нескольких пользователей к определенным данным и возможности совершать с ними какие-либо операции, в многопользовательской информационной системе используются процедуры идентификации, аутентификации и авторизации. Прежде всего актора, который запрашивает данные или удаленно вызывает функцию, необходимо идентифицировать, т.е. определить его уникальный идентификатор, однозначно определяющий этого пользователя или внешний сервис. Первичное назначение этого идентификатора выполняется при процедуре регистрации. После регистрации пользователя в информационной системе сохраняется его идентификатор: ID, уникальное имя (логин) и/или другие учетные данные, которые будут использоваться при процедуре аутентификации. Аутентификация выполняется при входе актора в систему или при запросе ресурса и представляет собой проверку подлинности учетных данных, т.е. сравнение их значений с сохраненными ранее (при регистрации).
Возможность аутентифицированного пользователя выполнять с определенными данными какие-то операции называется авторизацией. Поэтому HTTP-ответ от сервера со статусом 401 (Unauthorized) означает невозможность выполнения клиентского запроса из-за недостатка учётных данных клиента. Иначе говоря, сервер не может предоставить клиенту права на выполнение операций с данными, т.к. клиент не аутентифицирован. Если же клиент аутентифицирован, т.е. выполнен вход в систему и/или в заголовке HTTP-запроса, отправляемого на сервер, указаны учетные данные, но этому клиенту не разрешено выполнять запрошенную операцию, сервер вернет HTTP-ответ со статусом 403 (Forbidden). Это означает, что аутентифицированному клиенту запрещен доступ к запрашиваемому ресурсу и/или вызываемой операции. Справедливости ради стоит отметить, что при скрытии ресурса ото всех пользователей сервер тоже может выдавать ответ со статусом 403 на запрос клиента.
Когда взаимодействие между клиентом и сервером происходит не напрямую, а через прокси-сервер, последний тоже может запрашивать учетные данные для выполнения запросов на серверном приложении. В частности, об этом говорит HTTP-ответ со статусом 407 (Proxy Authentication Required). А вот HTTP-ответ со статусом 511 (Network Authentication Required) показывает необходимость аутентификации клиента перед предоставлением доступа к сети. Такой статус HTTP-ответа генерируется не сервером приложения, а прокси-сервером, который контролируют доступ к сети. Это частая ситуация в местах публичного пользования, таких как кафе, гостиница, аэропорт и пр. Идентификация клиентов при этом выполняется по MAC-адресу устройства, с которого совершалась попытка выхода в сеть, по логину и паролю, выданному при регистрации в гостинице, номеру телефона или другим учетным данным.
Основы архитектуры и интеграции информационных систем
Код курса
OAIS
Ближайшая дата курса
20 января, 2025
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
Чтобы наглядно резюмировать отличия идентификации, аутентификации и авторизации в веб-приложениях, составим UML-диаграмму последовательности, расширив пример из моей прошлой статьи. Однако, сперва составим UML-диаграмму Use Case, чтобы показать, какие возможности предоставляет интернет-магазин предоставляет своим пользователями. Все пользователи могут просматривать каталог всех товаров, искать товары определенных характеристик с применением различных фильтров, а также просмотреть детали конкретного товара. Добавить товар в корзину и купить его через шлюз онлайн-оплаты (внешняя система по отношению к интернет-магазину) может только покупатель, который должен быть аутентифицирован. Добавление нового товара и его модификация доступны лишь менеджеру интернет-магазина.
Подробнее о том, как составить такую диаграмму я расскажу в следующий раз, а пока отмечу, что эта UML-диаграмма Use Case была сделана в веб-движке PlantUML (https://www.plantuml.com/) через следующее текстовое определение:
@startuml
skinparam packageStyle rectangle
actor Пользователь
actor Менеджер
actor Покупатель
actor Шлюз_онлайн_оплаты
Пользователь <|-- :Менеджер:
Пользователь <|-- :Покупатель:
rectangle Интернет_магазин {
Пользователь --> (Войти в систему)
(Регистрация) .> (Войти в систему) : extend
(Аутентификация) .> (Войти в систему) : extend
(Купить товар) .-> (Аутентификация) : include
(Добавить новый товар) .-> (Аутентификация) : include
Пользователь --> (Найти товар)
(Посмотреть товар) .> (Найти товар) : extend
Менеджер --> (Добавить новый товар)
(Изменить товар) ..> (Добавить новый товар) : extend
(Удалить товар) ..> (Добавить новый товар) : extend
(Найти товар) .-> (Просмотреть каталог) : include
(Купить товар) .-> (Сделать заказ) : include
(Сделать заказ) ..> (Добавить товар в корзину) : include
(Добавить товар в корзину) ..> (Посмотреть товар) : include
(Удалить товар из корзины) ..> (Добавить товар в корзину) : extend
(Изменить количество товара в корзине) ..> (Добавить товар в корзину) : extend
Покупатель --> (Купить товар)
(Купить товар) -- Шлюз_онлайн_оплаты
}
@enduml DDD, ООП и UML для аналитика
Код курса
BUML
Ближайшая дата курса
9 декабря, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
Для простоты рассматриваемого примера возьмем REST API, который предполагает выполнение CRUD-операций с ресурсами, привязанным к конечным точкам, через отправку HTTP-запросов. Возвращаясь к рассматриваемой теме про аутентификацию в API веб-приложений, составим UML-диаграмму последовательности для юзкейса «Добавить новый товар». В REST API веб-приложения интернет-магазина это будет выполняться через POST-запрос HTTP. На диаграмме отметим статусы HTTP-ответов в качестве значений от сервера, возвращаемых на вызов клиента. Чтобы разнести уровни абстракции (системный и пользовательский), разделим клиента веб-приложения на пользователя (актор) и браузер, через GUI которого он общается с сервером.
Как и предыдущая UML-диаграмма, эта диаграмма последовательности тоже была создана в веб-движке PlantUML через следующее текстовое определение:
@startuml actor Пользователь participant Браузер participant Интернет_магазин Пользователь -> Браузер: добавить товар Браузер -> Интернет_магазин : POST/products activate Интернет_магазин Интернет_магазин --> Браузер :401 (Unauthorized) Браузер -> Пользователь : запрос входа в систему Пользователь --> Браузер : учетные данные Браузер -> Интернет_магазин : POST/products с учетными данными Интернет_магазин -> Интернет_магазин : проверить учетные данные alt Пользователь зарегистрирован alt Пользователь Менеджер Интернет_магазин --> Браузер :201 (Created) Браузер --> Пользователь : id товара else Пользователь Покупатель Интернет_магазин --> Браузер : 403 (Forbidden) Браузер --> Пользователь : ошибка "операция не разрешена" end alt else Пользователь НЕ зарегистрирован Интернет_магазин --> Браузер :401 (Unauthorized) Браузер --> Пользователь : ошибка "неверные учетные данные" end alt deactivate Интернет_магазин @enduml
Далее более подробно посмотрим, какие бывают виды аутентификации, и чем они отличаются.
12 видов аутентификации веб-API в Postman
Чтобы гарантировать безопасный доступ клиента к данным на сервере, API используют авторизацию, что включает аутентификацию отправителя запроса и подтверждение того, что у него есть разрешение на манипуляции с ресурсом. При проектировании и реализации API разработчик может выбрать наиболее подходящий из возможных видов аутентификации. При интеграции с внешними системами придется использовать тот способ, который предполагает сторонний API.
В рамках задачи тестирования REST API аналитики часто используют Postman – удобный GUI-инструмент, который позволяет отправлять HTTP-запросы к веб-сервисам, передавая в заголовке запроса различные параметры, а в теле запроса – необходимые данные в разных форматах (XML, JSON, TXT). При этом также можно передавать учетные данные для аутентификации клиента на удаленном сервере. Эти учетные данные обычно включаются в заголовок HTTP-запроса WWW-Authenticate. Если посмотреть отладочную информацию в браузере, это будет выглядеть так:
В Postman при создании нового HTTP-запроса к REST API приложению на закладке Authorization можно выбрать нужный вид аутентификации.
На сегодня Postman поддерживает 12 видов аутентификации:
- Наследование авторизации (Inheriting authorization), что пригодится при группировке запросов в коллекции и папки для комплексного тестирования нескольких конечных точек одного веб-сервиса с разными HTTP-запросами, чтобы повторно использовать одни учетные данные вместо ввода этих параметров каждый раз при отправке запроса. По умолчанию запросы внутри коллекции или папки наследуют аутентификацию от родителя. Чтобы изменить это для отдельного запроса, надо выбрать другой вид аутентификации.
- Отсутствие авторизации (No auth), что не предполагает добавления учетных данных к запросу;
- ключ API (API key) – в заголовок или в параметры HTTP-запроса добавляется пара ключ-значение. Чтобы использовать это для тестирования, предварительно нужно получить ключ разработчика API на стороне тестируемого сервера.
- токен на предъявителя (Bearer token) – это веб-маркер JSON (JWT, JSON Web Token), который представляет собой текстовую строку, включенную в заголовок запроса. Аналогично предыдущему способу, чтобы использовать этот метод аутентификации, надо предварительно получить токен разработчика API от тестируемого сервера.
- JWT-носитель (JWT bearer), что предполагает генерацию носителя JWT прямо в Postman с использованием криптографических алгоритмов с SHA (HMAC, RSASSA-PKCS1-v1_5, ECDSA, RSASSA-PSS), секрета, закрытого ключа и полезной нагрузки для генерируемого JWT-токена в формате JSON.
- Базовая аутентификация (Basic auth) — отправка подтвержденного имени пользователя и пароля вместе с HTTP-запросом. Эти учетные данные добавляются в заголовок HTTP-запроса Authorization в кодировке Base 64. Это не самый безопасный способ, т.к. перехваченные данные легко раскодировать.
- Дайджест аутентификации (Digest auth), когда клиент отправляет первый запрос к API, а сервер отвечает несколькими деталями, включая одноразовый номер, значение области действия (realm) и HTTP-ответ со статусом 401. На это клиент снова отправляет серверу зашифрованный массив данных, включая имя пользователя и пароль, вместе с данными, полученными от сервера в первом запросе. Сервер использует переданные данные для создания зашифрованной строки, которую сравнивает со значением, полученным от клиента для проверки подлинности запроса. Для создания дайджеста и контрольной суммы Postman поддерживает алгоритмы MD5 и SHA, а регулировать качество защиты передаваемого сообщения можно параметром qop, значение которого указывается сервером в заголовке ответа WWW-Authenticate. Чтобы избежать атак с выбранным открытым текстом, обеспечить взаимную аутентификацию и обеспечить некоторую защиту целостности сообщения, в дайджест-аутентификации используется Client Nonce — непрозрачное строковое значение в кавычках, предоставленное клиентом. Регулировать количество запросов, отправленных клиентом со значением одноразового номера, помогает параметр Nonce Count.
- Протокол OAuth 2.0 – аутентификация через стороннего провайдера (например, войти через VK, Google, Github и пр.), которая позволяет клиентским приложениям получать доступ к данным, предоставляемым внешним API, не раскрывая имя пользователя и пароль. Как это выглядит на UML-диаграмме последовательности я рассказываю а примере аутентификации через ЕСИА здесь. Доступ к пользовательским данным с помощью OAuth 1.0 включает в себя несколько прямых и обратных запросов между клиентским приложением, пользователем и внешним провайдером. Протокол OAuth 1.0 иногда называют двусторонним (аутентификация только между клиентом и сервером) или трехсторонним (клиент запрашивает данные для пользователя стороннего сервиса). Чтобы запросить пользовательские данные с помощью стороннего сервиса, клиентское приложение запрашивает маркер доступа, используя учетные данные, такие как ключ и секрет. Внешний провайдер выдает первоначальный токен, который не предоставляет доступ к пользовательским данным, а клиентское приложение запрашивает учетные данные у пользователя. Когда пользователь предоставляет аутентификацию, клиентское приложение отправляет запрос на обмен временного токена на токен доступа, проходя проверку авторизации пользователя. Внешний провайдер возвращает токен доступа, после чего клиентское приложение может запрашивать у него доступ к данным пользователя. Postman поддерживает OAuth Core 1.0 Revision A с протоколами HMAC-SHA1, HMAC-SHA256, HMAC-SHA512, RSA-SHA1, RSA-SHA256, RSA-SHA512 и PLAINTEXT. Если серверу нужна подпись HMAC или PLAINTEXT, в Postman заполняются поля Consumer Key, Consumer Secret, Access Token и Token Secret. При использовании подписи RSA, Postman предоставит входные данные Consumer Key, Access Token и Private Key. Все эти данные аутентификации в Postman можно включить в заголовки или в тело HTTP-запроса. При отправке учетных данных OAuth 1.0 в заголовках, заголовок аутентификации, отправляющий значения ключа и секрета, добавляется к строке OAuth вместе с дополнительными обязательными данными, разделенными запятыми. При отправке данных OAuth 1.0 в теле и URL-адресе, учетные данные добавятся в тело или в параметры HTTP-запроса в зависимости от метода. Для методов POST и PUT параметры аутентификации будут добавлены в тело запроса. В GET-запросе данные ключа и секрета будут переданы в параметрах URL-запроса, что небезопасно.
- Протокол OAuth 2.0 является развитием предыдущего вида и предполагает получение токена доступа к API, а затем его использование для проверки подлинности запросов. Обычно доступ к данным с помощью OAuth 2.0 отличается у разных провайдеров API, но включает несколько прямых и обратных запросов между клиентским приложением, пользователем и API. Клиентское приложение отправляет пользователю запрос на авторизацию доступа к своим данным. Если пользователь предоставляет доступ, приложение запрашивает маркер доступа у внешнего провайдера, передавая разрешение на доступ от пользователя и данные аутентификации для идентификации клиента. Провайдер проверяет эти сведения и возвращает токен доступа, который использует клиент для запроса пользовательских данных у провайдера. Postman позволяет указать конкретные данные в зависимости от типа гранта OAuth 2.0, который может быть кодом авторизации, неявным, учетными данными пароля или учетными данными клиента. Наименее безопасно использовать учетные данные пароля или клиента, а также неявный тип предоставления. В отличие от 1-ой версии протокола, токен в OAuth 2.0, сгенерированный в Postman, имеет ограниченный срок действия. Postman автоматически обновляет его в фоновом режиме, перед отправкой запроса с ним. Обновленный токен доступа обновляется во всех запросах, в которых он используется.
- Аутентификация Hawk (Hawk authentication) позволяет использовать частичную криптографическую проверку, задав Hawk Auth ID, Hawk Auth Key и алгоритм хеширования для создания кода аутентификации сообщения (MAC).
- Подпись AWS (AWS Signature) для запросов к веб-сервисам Amazon. AWS использует для аутентификации специальную схему HTTP, основанную на ключе HMAC (код аутентификации хэш-сообщения) с ключом доступа и секретом.
- NTLM-аутентификация (Windows Challenge/Response) — поток аутентификации для операционной системы Windows и автономных систем с указанием домена или хоста.
- Akamai EdgeGrid от провайдера веб-услуг Akamai, что включает учетные данные (токен доступа, токен клиента и секрет клиента), полученные при регистрации клиентского приложения в Akamai.
После краткого знакомства с видами аутентификации, поддерживаемыми в Postman, возникает вопрос: зачем их так много? Частично ответ на этот вопрос содержится в кратком описании каждого вида и сводится к удобству его практического применения. Например, Подпись AWS (AWS Signature) отлично подходит для тестирования приложений, развернутых на платформе AWS, NTLM-аутентификация – хороший выбор для автономных приложений, дайджест-аутентификация обеспечивает безопасность благодаря поддержке криптографических алгоритмов, а протоколы OAuth позволяют не хранить учетные данные пользователя, а реализовать аутентификацию как сервис в стиле микросервисной архитектуры ПО. В заключение стоит еще раз подчеркну, что выбор вида аутентификации при проектировании и реализации приложения относится к области ответственности архитектора или ведущего разработчика, а не аналитика. Аналитику вполне достаточно обзорных знаний про эти методы проверки подлинности клиента на сервере, а также понимания, чем аутентификации отличается от авторизации, что я и постаралась раскрыть в этой статье. С практической точки зрения эти сведения могут пригодиться аналитику в задачах реверс-инжиниринга, т.е. тестирования существующей системы, а также при разработке нефункциональных требований.
Как применить эти знания при проектировании веб-API, читайте в моей новой статье.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
2 декабря, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
Подробнее освоить все рассмотренные темы по архитектуре и интеграции информационных систем, вы сможете на курсах Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
- Основы архитектуры и интеграции информационных систем
- UML для бизнес-аналитика
- Разработка ТЗ на информационную систему по ГОСТ и SRS
Источники
