null

Основные методы аутентификации для REST API

9 October 2024 0 Romo Fedoroff

Введение

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

Аутентификация и авторизация: в чем разница?

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

Аутентификация – это процесс подтверждения личности. Это как предъявление водительских прав, которые подтверждают, что вы – это именно вы.

Авторизация – это проверка права доступа. Например, у вас может быть пропуск, который открывает только определенные двери на рабочем месте, но не все.

Основные методы аутентификации для REST API

1. Схемы HTTP аутентификации (Basic и Bearer)

Протокол HTTP определяет схемы аутентификации безопасности HTTP, такие как:

  • Basic
  • Bearer
  • Digest
  • OAuth
  • и другие...

Мы рассмотрим две самые популярные, которые чаще всего используются для REST API.

Базовая аутентификация (Basic Authentication)

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

Вот пример использования базовой аутентификации в заголовке запроса: Authorization: Basic dP77xQmTEdY93ZxER==

Метод не требует использования cookies, сессий, страниц входа или других специальных решений, а также не требует сложных процедур типа handshake.

Однако, несмотря на простоту, Basic аутентификация не считается безопасной, и её следует использовать только с HTTPS (SSL).

Аутентификация по токену (Bearer Authentication)

Аутентификация по токену (также называемая аутентификацией по токену Bearer) — это схема аутентификации HTTP, которая включает использование токенов безопасности, называемых токенами Bearer.

Название «Bearer аутентификация» можно понимать как «предоставить доступ обладателю этого токена». Токен Bearer предоставляет доступ к определенному ресурсу или URL и обычно представляет собой зашифрованную строку, которая генерируется сервером в ответ на запрос авторизации.

Клиент должен отправить этот токен в заголовке Authorization при запросе защищенных ресурсов: Authorization: Bearer <токен>

Схема аутентификации Bearer была изначально создана как часть OAuth 2.0 в RFC-6750, но иногда используется и отдельно.

Так же, как и базовая аутентификация, аутентификация Bearer должна использоваться только через HTTPS (SSL).

2. API-ключи

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

API ключи часто передаются в строке запроса, что делает их уязвимыми для перехвата. Лучше всего передавать ключ в заголовке Authorization:

Authorization: ApiKey apiKeyValue

Хотя API ключи просты в реализации и применимы в сценариях с ограниченным функционалом (например, только для "чтения"), они остаются подверженными атакам, если ключи попадают в ненадежные руки.

3. OAuth (2.0)

Предыдущие версии этой спецификации, OAuth 1.0 и 1.0a, были значительно сложнее, чем OAuth 2.0. Самое большое изменение в последней версии заключается в том, что больше не требуется подписывать каждый вызов с помощью хэширования с ключом. Наиболее распространенные реализации OAuth используют один или оба из следующих токенов:

  • Токен доступа (access token): отправляется как API-ключ, позволяет приложению получать доступ к данным пользователя; токены доступа могут истекать по времени.
  • Токен обновления (refresh token): является необязательной частью процесса OAuth и используется для получения нового токена доступа, если предыдущий истек. OAuth 2.0 объединяет аутентификацию и авторизацию, позволяя более гибко управлять областью действия и сроком действия.

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

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

Популярные потоки OAuth 2.0

Потоки (также называемые типами грантов) — это сценарии, при которых API-клиент получает токен доступа от сервера авторизации.

OAuth 2.0 предоставляет несколько популярных потоков, подходящих для различных типов API-клиентов:

  • Authorization code (Код авторизации) – Самый распространенный поток, в основном используется для серверных и мобильных веб-приложений. Этот поток похож на процесс регистрации пользователей в веб-приложении с использованием учетной записи.
  • Implicit (Имплицитный поток) – Этот поток требует, чтобы клиент напрямую получил токен доступа. Это полезно в случаях, когда учетные данные пользователя не могут храниться в коде клиента, поскольку они могут быть легко доступны третьим лицам. Подходит для веб-, настольных и мобильных приложений, которые не имеют серверного компонента.
  • Resource owner password (Пароль владельца ресурса) – Требует ввода имени пользователя и пароля. Поскольку в этом случае учетные данные будут частью запроса, этот поток подходит только для доверенных клиентов (например, официальных приложений, выпущенных провайдером API).
  • Client Credentials (Учетные данные клиента) – Предназначен для аутентификации между серверами, этот поток описывает подход, при котором клиентское приложение действует от своего имени, а не от имени конкретного пользователя. В большинстве сценариев этот поток позволяет пользователям указывать свои учетные данные в клиентском приложении, чтобы оно могло получать доступ к ресурсам под контролем клиента.

4. OpenID Connect

OpenID Connect — это простая идентификационная надстройка над протоколом OAuth 2.0, которая позволяет клиентам вычислительной системы проверять личность конечного пользователя на основе аутентификации, выполненной сервером авторизации, а также получать основную информацию о профиле пользователя в совместимом и REST-подобном формате.

С технической точки зрения, OpenID Connect использует RESTful HTTP API и JSON как формат данных.

OpenID Connect позволяет различным клиентам, включая веб-клиенты, мобильные и JavaScript-клиенты, запрашивать и получать информацию о подтвержденных сеансах и конечных пользователях. Спецификация является расширяемой и поддерживает дополнительные функции, такие как шифрование данных идентификации, обнаружение OpenID-провайдеров и управление сеансами.

OpenID Connect определяет поток входа, который позволяет клиентскому приложению аутентифицировать пользователя и получать информацию (или «claims») об этом пользователе, такую как имя пользователя, электронная почта и т. д. Информация о личности пользователя кодируется в безопасном JSON Web Token (JWT), называемом ID-токеном.

JSON Web Token (JWT) — это открытый стандарт (RFC 7519), представляющий собой метод безопасного представления заявлений между двумя сторонами. JWT позволяет декодировать, проверять и генерировать токены. Хотя JWT является стандартом, он был разработан компанией Auth0, которая занимается управлением идентификацией и аутентификацией с помощью API.

OpenID Connect определяет механизм обнаружения, называемый OpenID Connect Discovery, при котором сервер OpenID публикует свои метаданные по известному URL-адресу, обычно https://server.com/openid-configuration.

Этот URL возвращает JSON-список конечных точек OpenID/OAuth, поддерживаемые области и заявления, открытые ключи, используемые для подписания токенов, и другие детали. Клиенты могут использовать эту информацию для формирования запроса к серверу OpenID. Имена полей и значения определены в спецификации OpenID Connect Discovery.

Небольшое обобщение

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

  • Легко реализуется, поддерживается практически всеми веб-серверами.
  • Включает отправку имени пользователя и пароля, закодированных в Base-64.
  • Не должна использоваться без SSL.
  • Легко комбинируется с другими методами безопасности.

Примечание: базовая аутентификация очень уязвима для перехвата и атак типа "человек посередине" при отсутствии шифрования. Из-за этого ограничения этот метод аутентификации рекомендуется использовать только в сочетании с SSL.

OAuth1.0 (схема Digest)

  • Популярный, проверенный, безопасный, основанный на сигнатуре, хорошо определённый протокол.
  • Использует криптографическую подпись, которая представляет собой комбинацию секретного токена, nonce и другой информации на основе запроса.
  • Может использоваться как с SSL, так и без него.

OAuth2 (схема Bearer Token)

  • Текущая спецификация OAuth2 устраняет необходимость в криптографических подписях, паролях и именах пользователей.
  • OAuth2 работает с различными сценариями аутентификации, называемыми "потоками", которые включают:
    • Поток с кодом авторизации (Authorization Code flow)
    • Имплицитный поток (Implicit flow)
    • Поток пароля владельца ресурса (Resource Owner Password flow)
    • Поток учетных данных клиента (Client Credentials flow)

OpenID Connect Discovery

  • Основан на протоколе OAuth 2.0.
  • Использует поток входа, который позволяет клиентскому приложению аутентифицировать пользователя и получать доступ к информации.
  • Информация о пользователе кодируется с помощью безопасного токена JSON Web Token (JWT).

Заключение

Из четырех рассмотренных методов, наиболее предпочтительным для аутентификации и авторизации в REST API является OAuth 2.0. Он предлагает множество преимуществ, таких как простота использования, поддержка различных сценариев и высокий уровень безопасности. OpenID Connect набирает популярность благодаря своей интеграции с OAuth 2.0 и возможности работы с пользовательскими данными. Тем не менее, API ключи и схемы HTTP аутентификации все еще могут быть применимы в специфических сценариях, особенно в условиях ограниченного функционала.

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