Выбрать страницу

В современной экономике, управляемой ИТ, веб-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.

В дайджест аутентификации, это сервер, который обнаруживает клиента, который пытается получить доступ к ресурсу. Сервер будет генерировать уникальное значение, именуемое «nonce». Позже это уникальное значение будет использоваться ресурсным запрашиваем для создания хэша 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

Ключи API

 

Токен на предъявителя

Токен на предъявителя

 

OAuth 2.0

OAuth 2.0 и Open ID Connect более сложны в настройке. Я покажу вам демо для OAuth 2.0. Существует простой способ сделать OAuth 2.0 аутентификации, которые я объясню после этого раздела.

 

Шаг 1: Сервер аутентификации OAuth

Настройка деталей сервера аутентификации OAuth.

Проверка подлинности OAuth

 

Шаг 2: Учетные данные

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

 

Учетные данные проверки подлинности OAuth

 

Шаг 3: Информация о сервере

Сервер API запрашивает сервер аутентификации для получения информации о пользователе.

Информация о сервере аутентификации OAuth

 

Шаг 4: Токен доступа

Серверы API идентифицируют пользователя и отвечают токеном доступа. Затем пользователь отправляет токен доступа на сервер API по каждому запросу. Сервер API проверяет и дает доступ к приложению.

Токен доступа к аутентификации OAuth

 

 

Проверка подлинности API: Вариант 2

Если первый вариант неосуществим, вы можете записать его с помощью инструмента записи Веб Рекордер EveryStep. Вы можете получить доступ к нему через Интернет и с помощью рекордера проще и эффективнее. Кроме того, вам не нужно изучать различные механизмы аутентификации. Здесь мы собираемся продемонстрировать, как сделать тестирование нагрузки с помощью LoadView и с помощью EveryStep Web Recorder. Приложение использует OAuth 2.0 для проверки подлинности.

 

Шаг 1: Запись нового сценария

Войдите в LoadView и под Выберите тип тестирования нагрузки,выберите веб-приложений. Или просто откройте веб-регистратор EveryStep,введите URL-адрес и начните запись.

 

OAuth записать новый сценарий

 

Шаг 2: Перейдите на функциональность входа

OAuth Войти в

OAuth Знак в шаге 2

 

Ну вот. Вы записали аутентификацию приложения, имея OAuth 2.0. Повторите записанный сценарий и убедитесь, что все работает, как ожидалось. Разве это не просто? После записи можно перейти к следующим шагам для выполнения теста нагрузки.

 

Заключительные мысли: Загрузите тестирование веб-API, требующих аутентификации

Соотнесение механизмов аутентификации HTTP не является легкой задачей с использованием любого инструмента тестирования производительности. Вы должны иметь практический опыт и глубокие знания о том, как работает поток аутентификации. Кроме того, очень важно сделать тестирование нагрузки для вашей функциональности входа. Если ваш модуль входа не в состоянии обслуживать ожидаемую одновременной загрузки пользователя, это будет огромная потеря для вашего бизнеса. Вход в приложение является важной частью функциональности вашего приложения. Если вы ищете хорошее решение для тестирования производительности для веб-api, вам определенно понюхает LoadView. Идите вперед и дать ему попробовать сегодня!