user

Авторизация

Добро пожаловать!

Регистрация

Graf

Кодинг

5 основных стратегий аутентификации REST API

 За последнее десятилетие REST API стали де-факто архитектурным подходом для современных платформ веб-приложений и мобильных приложений. Они разделяют уровни данных и представления, позволяя системам масштабироваться по размеру и совершенствованию функций с течением времени.

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

 С этой целью существует пять основных подходов к аутентификации в REST API, которые важно понимать. Каждый из этих подходов имеет свои преимущества, но также представляет различные уровни сложности — от простой проверки учетных данных до уровней проверки разрешений, контролируемых прокси-сервером.

Базовая аутентификация

 Обычная проверка подлинности — это подход проверки подлинности на основе HTTP, который является самым простым способом защиты REST API. Он использует формат Base64 для кодирования имен пользователей и паролей, которые хранятся в заголовке HTTP. Это эффективный подход к настройке различных учетных данных для доступа к API, когда приоритетом является то, чтобы приложение оставалось легким и простым. Однако этот подход не предлагает готовой поддержки многофакторной проверки подлинности ( MFA ) или динамических учетных данных для конкретных пользователей, что потребовало бы использования дополнительных расширений на основе браузера и инструментов авторизации.

 Благодаря своей простоте базовая аутентификация пользуется широкой поддержкой в ​​цепочках инструментов разработки, технологиях и платформах. Однако одна из основных проблем с этой схемой аутентификации заключается в том, что конфиденциальные учетные данные часто передаются между системами в незашифрованном виде. Следовательно, использование каналов Secure Sockets Layer ( SSL ) и Transport Layer Security ( TLS ) является обязательным при обмене конфиденциальными данными между несколькими веб-приложениями, особенно сторонними приложениями, поскольку злоумышленники могут перехватывать трафик, проходящий через незащищенные каналы, и красть учетные данные.

Ключи API

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

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

 К сожалению, ключи API подвержены тем же рискам, что и обычная проверка подлинности, поскольку хакеры могут перехватить и использовать соответствующие учетные данные. Хотя они предоставляют уникальный механизм идентификации для взаимодействия с пользователем переднего плана, который может как применять, так и отзывать учетные данные по запросу, простота его конструкции ограничивает его способность поддерживать многоуровневую аутентификацию или MFA.

HMAC-шифрование

 Другая форма аутентификации REST API, известная как код аутентификации сообщений на основе хэша ( HMAC ), часто используется, когда целостность полезных данных REST API является приоритетом. HMAC использует симметричное шифрование, иногда называемое шифрованием с одним ключом, для определения хеширования полезных данных REST API. Затем он генерирует уникальный код, связанный с этим хешированием, и прикрепляет этот код к соответствующим сообщениям. Вызывающий и получатель будут совместно использовать ключ и использовать его для обеспечения целостности данных в полезной нагрузке.

 Для иллюстрации приведем базовый пример аутентификации HMAC:

  • Разработчик использует URL-адреса для предоставления доступа к данным REST API, но хочет, чтобы срок действия этих URL-адресов истекал через определенный период.
  • Продолжительность сеанса и отметка времени истечения срока действия помещаются в URL-адрес и подписываются с использованием ключа шифрования HMAC.
  • Клиентский сервер, вызывающий API, использует ключ шифрования, встроенный в URL-адрес, для проверки полезной нагрузки данных. И клиент, и сервер пометят URL-адрес как просроченный по истечении указанного срока.
  • Если клиент или сервер обнаружит какие-либо неожиданные изменения в URL-адресе или получит сообщение, в котором используется URL-адрес с истекшим сроком действия, он предупредит API о несоответствии подписи ключа и предложит ему отклонить запросы на доступ.

 Подход HMAC к аутентификации REST API требует небольших операционных издержек с точки зрения управления или инструментов. Это полезно в сценариях, когда вы можете напрямую управлять как клиентскими, так и серверными приложениями. Однако может возникнуть проблема с безопасным хранением ключей шифрования при работе с мобильными и веб-приложениями, которые находятся вне вашего контроля.

 Например, мобильное приложение, использующее ключи шифрования HMAC на основе URL для облегчения запросов данных, является уязвимой целью для атак, особенно если эти ключи шифрования не имеют фиксированного срока действия. Если субъект угрозы получает этот уникальный ключ, он может легко заставить приложение принять вредоносную полезную нагрузку данных, просто внедрив украденный код шифрования в URL-адрес.

OAuth 2.0

 OAuth (в частности, OAuth 2.0) считается золотым стандартом, когда речь идет об аутентификации REST API, особенно в корпоративных сценариях, включающих сложные веб-приложения и мобильные приложения. OAuth 2.0 может поддерживать динамические наборы пользователей, уровней разрешений, параметров области и типов данных. Это предпочтительный подход для организаций, стремящихся защитить большое количество REST API, содержащих конфиденциальную информацию.

 OAuth 2.0 создает токены защищенного доступа, которые периодически обновляются с использованием ряда протоколов процедурной проверки, известных как типы предоставления . Эти типы грантов действуют как прокси-механизмы аутентификации, которые направляют поток запросов на доступ к API, не раскрывая базовые учетные данные, токены и другую информацию аутентификации, связанную с этими запросами.

 Пять основных типов грантов в OAuth 2.0:

  • Код авторизации
  • Ключ подтверждения для обмена кодами (PKCE)
  • Учетные данные клиента
  • Код устройства
  • Обновить токен

 В дополнение к повторному использованию ключей доступа OAuth поддерживает концепцию областей — метод ограничения доступа приложения к учетной записи пользователя и связанным учетным данным. Это помогает контролировать степень доступа сторонних приложений к данным учетной записи пользователя. Еще одним преимуществом этого подхода является возможность определять несколько областей и выдавать уникальные токены для разных типов запросов и уровней разрешений.

 OAuth может использовать веб-токен JSON ( JWT ) для проверки целостности полезной нагрузки, используя процесс, аналогичный подходу аутентификации HMAC, описанному в последнем разделе. Токены JWT надежно хранят зашифрованные пользовательские данные, а затем передают эти данные между приложениями по мере необходимости. Поскольку эти веб-токены могут быть подписаны , токен можно наполнить новыми ролями и разрешениями пользователя после аутентификации пользователя. Токены могут быть легко признаны недействительными или переработаны по своему усмотрению.

 Добавление общего симметричного ключа к службам приложений может помочь всем участвующим службам одновременно проверять целостность маркера, а не с помощью серии проверок. Это снижает риск создания единой точки отказа в процессе проверки. Однако, как описано в предыдущих разделах, управление распределением симметричных ключей, необходимых для проверки целостности полезной нагрузки, представляет собой серьезную проблему безопасности в динамических средах приложений с высокой степенью масштабируемости.

Подключиться к OpenID

 OpenID Connect — это открытый стандартный протокол аутентификации, созданный поверх OAuth 2.0. Он предоставляет клиентскому приложению, называемому проверяющей стороной ( RP ), простой способ проверки личности пользователя. Этот единый стандарт упрощает обмен информацией без необходимости явного управления учетными данными для сторонних приложений.

 API-интерфейсы REST, охватываемые OpenID Connect, становятся пригодными для использования после того, как пользователи прошли аутентификацию с помощью RP. В конце концов, API, связанный с этим RP, может выполнять проверку, используя собственный вариант типов грантов OAuth, упомянутых выше. Эти типы грантов:

  • Код авторизации
  • Скрытый
  • Гибридный

 Хотя OpenID Connect всегда находится под контролем поставщика API, несколько RP могут использовать эти типы предоставления самостоятельно по мере необходимости. Этот подход идеален для поставщиков REST API, которые не могут поддерживать сложные динамические инструменты управления учетными данными корпоративного уровня, но нуждаются в безопасном обмене пользовательскими данными между различными сторонними веб-приложениями.

Выбор подхода аутентификации REST API

 Учитывая разнообразие подходов к аутентификации REST API, тщательно взвесьте плюсы и минусы каждого подхода в соответствии с вашими уникальными требованиями к приложению перед его внедрением. Подход базовой аутентификации, ориентированный на HTTP, отлично подходит для ограничения публичного доступа к данным и ресурсам с низким уровнем риска, но все же требует, по крайней мере, некоторого уровня контроля безопасности. Между тем ключи API подходят для сценариев, когда поставщикам API необходимо идентифицировать отдельных потребителей и регулировать их разрешения по мере необходимости.

 Конфиденциальность данных, конечно, является основной частью решения. В то время как HMAC обеспечивает достаточную поддержку целостности полезной нагрузки данных для относительно изолированных операций, OAuth лучше подходит для сложных случаев использования, которые включают ротацию токенов доступа и настраиваемые уровни разрешений. Для тех, кто находится посередине, OpenID обеспечивает хороший баланс между динамическим управлением доступом OAuth и простотой HMAC.

 Независимо от подхода всегда рекомендуется ограничивать доступ REST API к защищенным каналам SSL и TLS. Избегайте передачи конфиденциальных учетных данных в виде встроенных частей полезной нагрузки данных API, URL-адресов или строк запросов , поскольку приложения могут непреднамеренно сохранить копии этих учетных данных с помощью автоматизированных процедур регистрации. Наконец, автоматизируйте такие процедуры, как смена ключей шифрования, поскольку ручной подход может привести к повторяющимся упущениям и ошибкам.