Персональные токены доступа, аутентификация «машина-машина» и определение API-ключей и их реальные сценарии

Если вы разрабатываете программное обеспечение или продукт SaaS, вы часто сталкиваетесь с запросами на широко применимые кейсы или функции: API-запросы. Особенно клиенты крупных предприятий могут захотеть программный доступ к ресурсам, будь то на личном уровне или на уровне организации.

В таких случаях часто требуются API-ключи, персональные токены доступа (PATs) и аутентификация «машина-машина» (M2M). В этой статье мы рассмотрим различия между этими методами и способы их использования в разработке продуктов для бизнеса (B2B) для разработчиков.

Сходства#

Давайте сначала взглянем на сходства между этими тремя методами.

1. Цель безопасности: Все три метода используются для защиты и контроля доступа к API, сервисам или ресурсам. Они все служат средством аутентификации и/или авторизации.
2. Подход на основе токенов: Каждый метод обычно включает использование уникальной строки или токена для идентификации. Эти токены обычно отправляются вместе с API-запросами, часто в заголовках или в качестве параметров запроса.
3. Отзыв: Токены или ключи в каждом из этих методов могут быть аннулированы или заменены, если они были скомпрометированы или больше не нужны. Это позволяет быстро реагировать на угрозы безопасности, не изменяя основную систему.
4. Программируемый доступ: Все три метода облегчают программный доступ к API или сервисам. Они позволяют автоматизацию и интеграцию между различными системами или приложениями.
5. Аудитирование: Использование этих методов аутентификации может быть зафиксировано и подлежит аудиту. Это позволяет отслеживать доступ к API, мониторить подозрительную активность и предоставлять отчеты о соблюдении требований.
6. Адаптируемость к контролю доступа: Все три метода могут быть реализованы с различными уровнями контроля доступа и разрешений. Они могут быть адаптированы к различным моделям безопасности и архитектурным требованиям.
7. Независимость от протоколов: Хотя эти методы часто используются с REST API, их можно применять к различным типам API и протоколов.

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

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

Различия#

API-ключи#

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

Как работают API-ключи?#

API-ключ выдается провайдером API и передается зарегистрированному потребителю API [1], который включает его в каждый запрос. Сервер API затем проверяет API-ключ для подтверждения личности потребителя, прежде чем вернуть запрашиваемые данные.

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

[1]: Потребитель API - это любое приложение, сервис или пользователь, который взаимодействует с API для доступа к его функциям или данным. Они отправляют запросы к API для выполнения операций, таких как извлечение, создание, обновление или удаление ресурсов. Потребителями API могут быть веб-приложения, мобильные приложения, другие серверы или даже отдельные разработчики, которые используют API для интеграции с другими сервисами или для создания новых функций на существующих платформах.

Postman: Что такое API-ключ?

Кейсы использования#

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

Пример 1: Интеграция с Zapier#

Zapier: Добавить аутентификацию с использованием API-ключа

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

Пример 2: Интеграция со Stripe#

Stripe использует API-ключи для безопасной интеграции с различными платформами и приложениями. Используйте Dashboard разработчика для создания, просмотра, удаления и обновления API-ключей.

Персональные токены доступа (PATs)#

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

Как работают PATs#

1. Создание и управление: Пользователи генерируют PATs через настройки своих аккаунтов на соответствующей платформе.
   • Например, на GitHub пользователи могут создавать PATs с точными или основными разрешениями и сроками действия.
   • В таких продуктах Atlassian, как Jira и Confluence, пользователи могут создавать PATs в настройках профиля, задавая имя токена и необязательный срок действия.
2. Использование: PATs используются как Bearer-токены в заголовке Authorization API-запросов. Это значит, что они включаются в HTTP-заголовки для аутентификации запроса.
   • Они обеспечивают безопасный доступ к ресурсам API, позволяя пользователям выполнять действия, такие как создание, чтение, обновление и удаление ресурсов в зависимости от разрешений, предоставленных токену.
   • PATs могут использоваться в нескольких приложениях внутри одной платформы, предоставляя единый способ управления доступом и разрешениями.
3. Отзыв и установка срока действия:
   • PATs обеспечивают улучшенную безопасность, позволяя пользователям отзывать токены в случае их компрометации, без необходимости менять пароль аккаунта.
   • Платформы часто рекомендуют устанавливать сроки действия PATs для уменьшения риска эксплуатации долго живущих токенов.

Кейсы использования#

Существует два типичных сценария использования,

Автоматизация и скрипты

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

Например, пользователи GitHub могут создавать PATs для аутентификации операций Git по HTTPS и взаимодействия с REST API GitHub. Это полезно для разработчиков, которые нуждаются в автоматизации задач, таких как клонирование репозиториев, отправка коммитов или управление задачами и pull-запросами.

Интеграция с внешними приложениями

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

Например, менеджер проекта использует PAT для интеграции инструмента управления проектами с внешней системой отслеживания проблем, что позволяет осуществить бесперебойный обмен данными и синхронизацию, как в случае с Atlassian (Jira и Confluence).

Вышеупомянутые сценарии больше похожи на инструменты для разработчиков. Полезны ли PATs только для таких продуктов? Нет. Вот два дополнительных примера: один из систем управления контентом (CMS) и один из инструментов для повышения производительности.

Пример 1: Contentful#

Contentful: Персональные токены доступа

Contentful — это платформа headless CMS, которая предлагает PATs в качестве альтернативы OAuth-токенам для доступа к их Content Management API (CMA).

Основные особенности включают:

• Пользователи могут создавать несколько токенов с различными уровнями доступа и разрешениями.
• Токены привязаны к аккаунту пользователя, наследуя его разрешения.
• PATs особенно полезны для разработки и автоматизации.

Пример 2: Airtable#

Создание персональных токенов доступа | Поддержка Airtable

Airtable — облачная платформа для совместной работы, реализует PATs для доступа к API.

Их система позволяет:

• Создание нескольких токенов с разными уровнями доступа и разрешениями.
• Токены могут быть ограничены конкретными базами данных или рабочими пространствами.
• Администраторы на уровне предприятия могут создавать токены с более широкими полномочиями для всей организации.

Аутентификация «машина-к-машине» (M2M)#

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

Приложения типа «машина-машина» (M2M) сейчас используют Flow по учетным данным клиента, который описан в протоколе авторизации OAuth 2.0 RFC 6749. Оно также поддерживает аналогичные стандартные протоколы. Да, аутентификация M2M более строго соблюдает открытый стандарт по сравнению с PATs и API-ключами.

Она аутентифицирует само приложение или сервис, а не пользователя, и часто реализует JWT (JSON Web Tokens) для бесфайловой аутентификации. Это обеспечивает безопасное взаимодействие сервисов друг с другом в распределенных системах.

Как работает аутентификация «машина-к-машине»#

Она следует аналогичному процессу:

1. Учетные данные клиента: Каждая машина (или сервис) имеет уникальный клиентский идентификатор и секрет.
2. Запрос токена: Сервис отправляет эти учетные данные серверу авторизации.
3. Токен доступа: После проверки сервер авторизации выдает токен доступа, часто представляющий собой JWT.
4. API-запросы: Сервис использует этот токен для аутентификации и авторизации API-запросов к другому сервису.
5. Проверка: Принимающий сервис проверяет токен перед предоставлением доступа к своим ресурсам.

Кейсы использования#

Вот краткий пример использования аутентификации «машина-к-машине» (M2M) для взаимодействия между бэкенд-сервисами:

Ситуация: Сервис A должен получить доступ к данным сервисом B через его API.

1. Настройка:

   • Сервис A зарегистрирован как клиент на сервере авторизации.
   • Сервис A получает клиентский ID и секрет.

2. Аутентификация:

   • Сервис A запрашивает токен доступа у сервера авторизации:

3. Выдача токена:

   • Сервер авторизации проверяет учетные данные и выдает токен доступа JWT.

4. API-запрос:

   • Сервис A использует токен для запроса данных у сервиса B:

5. Проверка:

   • Сервис B проверяет токен у сервера авторизации.

6. Ответ:

   • Если токен действителен, сервис B возвращает запрошенные данные сервису A.

Этот процесс позволяет безопасно и автоматически взаимодействовать сервисам A и B без участия пользователей, используя Flow учетных данных клиента в OAuth 2.0.

Связь устройство-устройство

Связь устройство-устройство, особенно в контексте IoT (Интернет вещей), сильно зависит от аутентификации «машина-к-машине» (M2M) для обеспечения безопасного и эффективного обмена данными.

Например, в умном доме, умный термостат общается с центральным хабом автоматизации для изменения температурных настроек на основе предпочтений пользователя. Термостат использует M2M-аутентификацию для безопасной передачи данных хабу и получения команд, обеспечивая, что только авторизованные устройства могут взаимодействовать с системой отопления дома.

Ключевые моменты#

Окей, вы дошли до конца статьи. Можно краткое резюме? Конечно! Вот ключевые моменты:

1. Область применения: API-ключи широкие, PATs (персональные токены доступа) специфичны по пользователю, а токены M2M (машина-к-машине) специфичны по сервису.
2. Продолжительность жизни: API-ключи долгоживущие, PATs имеют короткий срок жизни, а токены M2M могут быть разными.
3. Представление: API-ключи – непрозрачные строки, PATs могут быть непрозрачными или структурированными, а M2M-токены часто используют JWT.
4. Кейсы использования: API-ключи используются для простого доступа к API, PATs - для операций, ориентированных на пользователя, а M2M-токены - для связи сервисов друг с другом.