В современной экономике, управляемой ИТ, веб-API все чаще используются во всем мире. Вы, вероятно, потребляли или создавали API самостоятельно. API обрабатывают огромные объемы данных – одна из основных проблем, связанных с организацией службы программного обеспечения, специально ищет для защиты этих данных. Идея заключается в том, что данные должны быть стабильными и защищенными и могут быть доступны только предназначенным пользователям. Время, скорость и производительность также имеют значение для API. Здесь, в этой статье, мы собираемся обсудить различные методы проверки подлинности API и авторизации, которые широко используются ИТ-организациями по всему миру.
Аутентификация против авторизации
Если вы когда-либо работали над API, вы всегда будете видеть только заготовки авторизаций, а не заготовки аутентификации. Вы когда-нибудь задумывались, почему? Просто используйте любой инструмент сетевого перехвата, такой как Fiddler / Wireshark, или используйте инструменты тестирования API и проверьте API вашего приложения. Независимо от того, видите ли вы заготовки или тело API, ваш запрос API всегда найдет авторизацию. Итак, прежде чем мы объясним, почему API имеют только авторизацию, а не аутентификацию, давайте сначала объясним разницу между аутентификацией и авторизацией.
аутентификация
Аутентификация является не чем иным, как проверкой пользователя, если он является правильным человеком для использования этой службы. Давайте объясним это далее с простым примером. Допустим, вы посещаете ресторан в вашем городе с семьей. Вы открываете дверь ресторана, и вас приветствует менеджер. Но вы не хотите сидеть в общественном обеденном месте в ресторане, вы хотите сидеть в частной комнате с семьей, и вы должны иметь бронирование для этого. Вы сообщите менеджеру, и они подтверждают, что у вас есть бронирование, что позволяет вам сидеть в частной секции ресторана, зарезервированной для семей. Итак, это то, что мы назвали аутентификацией. Менеджер ресторана разрешил вам посидеть с семьей в частном месте с действительным бронированием. Можно сказать, что бронирование называется ключом аутентификации.
авторизация
Теперь вам разрешено в частной комнате, и вы можете использовать услуги, зарезервированные для частных закусочных и т.д. Вы уполномочены делать все это, но если вы идете в кухню ресторана и открыть их холодильник они могут сказать вам, не допускаются в этой области. Так что это называется авторизацией. Таким образом, вы можете войти, но после входа в ресторан вы не уполномочены идти в некоторых областях и не уполномочены получить доступ к какой-либо другой области. Так вот что такое авторизация.
Теперь, когда дело доходит до веб-сайта, любой может войти на общедоступную страницу входа на веб-сайт. Так же, как любой может войти в ресторан. Никто тебя не остановит. Когда вы входите в систему с именем пользователя и паролем своего веб-сайта, вы аутентифицируетесь и можете войти на веб-сайт. Так же, как вы получили доступ к зарезервированной частный стол в ресторане, используя бронирование. Но затем после входа и после проверки подлинности вы можете получить доступ к некоторым разделам, но вы не сможете получить доступ к некоторым другим разделам, которые похожи на разделы администратора веб-сайта. Так что это очень простое различие между аутентификацией и авторизацией.
Теперь вернемся к нашему вопросу. Мы всегда видим авторизацию в API, почему это так? Если вы посмотрите на API, он указывает на конец точки, где этот адрес к конкретной функции или ресурса в приложении. Можно сказать, например, модуль на бэк-энде приложения. Когда вы действительно пытаетесь получить доступ к определенному ресурсу в одиночку в приложении, более уместно назвать его авторизацией для вас, хотя будет аутентификация для проверки вашей личности. Первым шагом всегда является аутентификация.
Типы аутентификаций HTTP
Поскольку мы рассмотрели разницу между аутентификацией и авторизацией, теперь мы обсудим различные типы аутентификаций API. Методы проверки подлинности API различаются в зависимости от метода, который они используют. Аутентификации очень важны, потому что они напрямую связаны с безопасностью вашей системы. Поэтому приоритет всегда отдается аутентификации HTTP в любой системе.
Мы подчеркем пять основных механизмов добавления безопасности в API – Basic, API Key, Bearer, OAuth1.0/OAuth 2.0 и OpenID Connect. Мы определим, что они делают, как они работают, и преимущества и недостатки каждого подхода. Наконец, мы продемонстрируем тестирование нагрузки API, который требует проверки подлинности с помощью LoadView.
Базовая аутентификация
В настоящее время ИТ-индустрия редко использует базовую аутентификацию HTTP, потому что ее очень легко взломать, но это самый простой способ реализации. API отправят имя пользователя и пароль вдоль тела. Учетные данные будут закодированы с помощью метода шифрования, такого как Base64; это преобразует имя пользователя и пароль в зашифрованный формат передачи.
Поскольку он использует заголовок для передачи учетных данных, никаких других сложных мер безопасности не применяется. Даже не сеансовых свия, ни файлов cookie.
Пример базовой аутентификации в заголовке запроса:
Авторизация: Основные Cg4sOnOlY8KyP
Дайджест аутентификации
Проверка подлинности доступа Digest является более сложной и продвинутой, чем базовая аутентификация. Digest использует комбинацию пароля пользователя и других атрибутов для создания хэша MD5. Затем он будет отправлен на сервер для проверки подлинности. Он более продвинутый, чем другой механизм безопасности, так как он отправляет учетные данные в качестве хэша. Первоначально он был создан в рамках RFC 2069, позже были добавлены улучшения безопасности в RFC 2617.
В дайджест аутентификации, это сервер, который обнаруживает клиента, который пытается получить доступ к ресурсу. Сервер сгенерирует уникальное значение, называемое одноразовым номером. Позже это уникальное значение будет использоваться ресурсным запрашиваем для создания хэша MD5, который будет проверен сервером.
Ключи API
В настоящее время клавиши API широко используются по сравнению с базовой аутентификацией. Вы можете увидеть его в мобильных приложениях, а также веб-приложений. Ключи API были созданы в некоторой степени для устранения уязвимостей безопасности, связанных с базовым механизмом API. В ключе API уникальное значение генерируется в серверной стороне после проверки подлинности с вашим именем пользователя и паролем. Он будет назначен пользователю. Как правило, это уникальное значение генерируется на основе IP-адреса и различных атрибутов пользователя. Большую часть времени разработчики отправляют ключ API в заголовок авторизации.
Пример ключа API
api_key: d670d200234faf5480aa11529b01d732
Есть, безусловно, много преимуществ использования ключа API, по сравнению со всеми другими механизмами безопасности. Прежде всего, ключи API просты с лучшей безопасностью. Недостатком является любой может забрать этот ключ безопасности с помощью любого из сетевых нюхают инструменты. Это может привести к проблемам безопасности всего приложения.
предъявитель
Носитель означает “человек или вещь, которая несет или держит что-то”. Как следует из названия, это схема проверки подлинности HTTP, которая включает маркеры безопасности. Носитель маркера безопасности получит доступ к определенным функциям или URL-адресам. Токен Bearer обычно генерируется сервером в ответ на запрос клиента на вход. После того, как пользователь имеет маркер на предъявителя с сервера, он должен отправить токен вместе с заголовком авторизации при дальнейших запросах.
Пример аутентификации носителя
авторизация:
Носитель eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJodHRwOi8vc2No’W1hcy54bWxzb2FwLm9y’y93cy8yMDA1LzA1L2lk-W50aXR5L2NsYWltcy9uYW1lIjoiNmUy’0NjUtNTRjg0YjVjW’yIiwi’XhwIjoxNTkzOTY3OD-0LCJpc3MiOiJodHwOlxcd3d3LnNvdWxib29rLm1lIiwiXVkIjoiaHR0cDpcXHd3dy5zb3VsYm9vay5t’SJ9.adcAYn8U5tn68EVGUGULYBKGC8Ohgxm7p45tDnpXVc
Первоначально он был создан как часть OAuth2.0 в RFC-6750. Есть, безусловно, много преимуществ использования токенов предъявителя по сравнению со всеми другими механизмами безопасности. Токены-носители лучше с точки зрения безопасности.
OAuth 1.0 и OAuth 2.0
OAuth является более безопасным протоколом для авторизации. OAuth обеспечивает простоту, обеспечивая при этом поток авторизации для приложений. OAuth обычно используется пользователями для входа на сторонние веб-сайты, используя свои аккаунты Google, Microsoft, Facebook, Slack, например, без разоблачения их учетных данных.
OAuth 1.0 подозревается в уязвимостях безопасности и больше не поддерживается. OAuth 2.0 оснащен расширенными функциями безопасности и является лучшим для идентификации и аутентификации личного аккаунта пользователя. OAuth 2.0 позволяет пользователям делиться своими конкретными атрибутами с приложением, сохраняя при этом свои учетные данные и другую информацию в тайне. OAuth 1.0 был гораздо сложнее и менее безопасным, чем OAuth 2.0. Самое большое изменение в OAuth2.0 заключается в том, что нет необходимости подписывать каждый звонок с помощью хэша с ключом.
В основном, OAuth состоит из двух токенов для проверки; токен аутентификации и токен сеанса. Токены аутентификации работают как ключевые протоколы безопасности API, приложение аутентиирует доступ к данным пользователей. Токены сеанса используются для поддержания сеанса пользователя и получения нового токена аутентификации в случае истечения срока действия токена сеанса. OAuth 2.0 сочетает в себе аутентификацию и авторизацию, чтобы обеспечить больше безопасности приложения.
В OAuth пользователь получит доступ к приложению с учетными данными. Затем приложение запрашивает токен аутентификации. Запрашиватель отправит этот запрос на сервер аутентификации, что позволит проверить подлинность, если учетные данные верны. Этот маркер аутентификации может быть проверен в любое время, независимо от пользователя. Это сделает OAuth гораздо более безопасным механизмом, чем другие проверки подлинности HTTP. Одним из основных недостатков OAuth является сложность реализации. Вы должны иметь хорошие знания в потоке OAuth, чтобы интегрировать его с вашим приложением.
Подключение OpenID
OpenID Connect является продолжением протокола OAuth 2.0. Он проверяет личность клиента на основе проверки подлинности, выполняемой сервером авторизации. Кроме того, он может получить информацию о профиле пользователя о клиенте. OpenID Connect фактически решает множество недостатков OAuth 2.0 и обеспечивает лучшее решение для конечных пользователей и разработчиков.
Какой протокол наилучшей аутентификации использовать?
Базовая аутентификация HTTP является самой простой для реализации в вашем приложении, но и не безопасной вообще. Учетные данные кодируются, но отправляются как простой текст. Проверка подлинности дайджеста улучшает базовую аутентификацию, отправляя данные в хэшированном формате. Но хэш алгоритма MD5 не является сложным на всех и может быть взломан очень легко. API ключи и предъявитель почти похожи и обеспечивают лучшую безопасность, что выше.
Протокол OAuth гарантирует, что никакие хакеры не с могут получить информацию о клиентах. Даже приложение не может получить учетные данные профиля клиента и личную информацию. OpenID Connect устанавливает протоколы для приложений для доступа к атрибутам клиента с помощью RESTful API. OpenID Connect расширяет поток токенов авторизации OAuth 2.0, вводя новые токены. В принципе, OpenID Connect реализуется как продолжение OAuth 2.0.
Использование LoadView для тестирования API, который требует аутентификации
В этом разделе мы собираемся внедрить аутентификацию HTTP API с помощью LoadView. LoadView позволяет выполнять эти задачи очень легко и эффективнее. Load View предоставляет два варианта тестирования загрузки api:
Проверка подлинности API: Вариант 1
Если у вас есть доступ к приложению, мы можем получить запрос API с помощью любого сетевого инструмента. Это самый простой метод. Мы покажем быструю демонстрацию для настройки каждого из вышеперечисленных механизмов аутентификации HTTP с помощью LoadView
Примечание: Вы можете получить данные о запросе сервера API и данные о телах от вашей команды разработчиков или захватить их с помощью любого инструмента для обработки данных сети.
Шаг 1: Выберите тип тестирования нагрузки
Войдите в LoadView и под Выберите тип тестирования нагрузки, выберите HTTP/S.
Шаг 2: Настройте API
Следующий экран попросит вас настроить API. Здесь мы покажем вам, как вы можете настроить различные механизмы проверки подлинности HTTP в LoadView.
Базовая аутентификация
Ключи API
Токен на предъявителя
OAuth 2.0
OAuth 2.0 и Open ID Connect более сложны в настройке. Я покажу вам демо для OAuth 2.0. Существует простой способ сделать OAuth 2.0 аутентификации, которые я объясню после этого раздела.
Шаг 1: Сервер аутентификации OAuth
Настройка деталей сервера аутентификации OAuth.
Шаг 2: Учетные данные
Введите учетные данные и нажмите на логин. Сервер аутентификации перенаправляет пользователя на ваш веб-сайт с кодом в качестве параметра URL.
Шаг 3: Информация о сервере
Сервер API запрашивает сервер аутентификации для получения информации о пользователе.
Шаг 4: Токен доступа
Серверы API идентифицируют пользователя и отвечают токеном доступа. Затем пользователь отправляет токен доступа на сервер API по каждому запросу. Сервер API проверяет и дает доступ к приложению.
Проверка подлинности API: Вариант 2
Если первый вариант неосуществим, вы можете записать его с помощью инструмента записи Веб Рекордер EveryStep. Вы можете получить доступ к нему через Интернет и с помощью рекордера проще и эффективнее. Кроме того, вам не нужно изучать различные механизмы аутентификации. Здесь мы собираемся продемонстрировать, как сделать тестирование нагрузки с помощью LoadView и с помощью EveryStep Web Recorder. Приложение использует OAuth 2.0 для проверки подлинности.
Шаг 1: Запись нового сценария
Войдите в LoadView и под Выберите тип тестирования нагрузки,выберите веб-приложений. Или просто откройте веб-регистратор EveryStep,введите URL-адрес и начните запись.
Шаг 2: Перейдите на функциональность входа
Ну вот. Вы записали аутентификацию приложения, имея OAuth 2.0. Повторите записанный сценарий и убедитесь, что все работает, как ожидалось. Разве это не просто? После записи можно перейти к следующим шагам для выполнения теста нагрузки.
Заключительные мысли: Загрузите тестирование веб-API, требующих аутентификации
Соотнесение механизмов аутентификации HTTP не является легкой задачей с использованием любого инструмента тестирования производительности. Вы должны иметь практический опыт и глубокие знания о том, как работает поток аутентификации. Кроме того, очень важно сделать тестирование нагрузки для вашей функциональности входа. Если ваш модуль входа не в состоянии обслуживать ожидаемую одновременной загрузки пользователя, это будет огромная потеря для вашего бизнеса. Вход в приложение является важной частью функциональности вашего приложения. Если вы ищете хорошее комплексное решение для тестирования производительности для своих веб-API, вам обязательно понравится LoadView. Идите вперед и дать ему попробовать сегодня!