Программная аутентификация: ключ API, персональный токен доступа и поток учетных данных клиента OAuth

Предыстория#

В разработке программного обеспечения, когда нам нужно программно получить доступ к ресурсам API через команды CLI или установить связь между серверными службами, мы обычно используем три механизма аутентификации: ключ API, персональный токен доступа (PAT) и поток учетных данных клиента OAuth (в Logto он именуется Machine-to-Machine). Но в чем же их различия? Какой из этих методов лучше использовать в конкретной ситуации? В этой статье блога мы углубимся в их сходства, различия и дадим представление о том, когда использовать каждый из них в различных сценариях.

Определения#

• Ключ API: Простая строка, которая может подтвердить ваш запрос к ресурсу API.
• Персональный токен доступа (PAT): Также простая строка, но представляет пользователя при использовании для аутентификации к ресурсу API. Это делегирование пользователя.
• Logto Machine-to-Machine (Logto M2M): Стандартный поток учетных данных клиента OAuth, который требует предварительной регистрации клиента, и требует использования идентификатора клиента и секрета для обмена на токен доступа. Таким образом, учетные данные Logto M2M представляют доверенного клиента, и природа потока учетных данных клиента OAuth делает его относительно сложным в использовании.

Сходства#

1. Цель аутентификации#

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

2. Меры безопасности#

• Все эти три метода аутентификации должны обрабатываться с учетом безопасности. Разработчики должны обеспечить безопасное хранение и передачу, чтобы предотвратить несанкционированный доступ.

Различия#

1. Контекст пользователя#

• Ключ API не идентифицирует пользователя и не предоставляет информации об авторизации. Поэтому ключи API часто используются для анонимного доступа к публичным данным или ресурсам. Не все услуги поддерживаются при использовании ключей API.
• PAT представляет идентификацию пользователя и будет представлять вас при запросе ресурса API. В некоторых системах PAT не разрешены для доступа к определенным услугам. Например, публикация пакетов NuGet в канале Azure Artifacts.
• Учетные данные Logto M2M могут использоваться только доверенными клиентами. Для аутентификации клиент должен быть предварительно зарегистрирован. При использовании учетных данных Logto M2M это представляет доверенного клиента, а не пользователя, который его использует.

2. Гранулярность разрешений#

• PAT и учетные данные Logto M2M обычно предлагают более точный контроль над разрешениями по сравнению с ключом API, позволяя детально контролировать, какие действия могут быть выполнены.

3. Формат токенов#

• Ключ API и PAT обычно являются непрозрачными строками, простыми и понятными.
• Токены доступа, выпущенные через механизм Logto M2M, обычно находятся в формате JWT.

4. Поток авторизации#

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

• Logto M2M использует стандартный OAuth 2.0 поток учетных данных клиента. Каждый клиент должен получить пару идентификатора клиента и секрета заранее, с которыми позже может обмениваться на токен доступа. Затем клиент использует токен доступа для доступа к ресурсу API.

Когда использовать каждый из них#

Ключ API#

• Связь служба-к-службе: Ключи API подходят для сценариев, где приложениям нужно напрямую взаимодействовать с API через CLIs. Например, вызов API OpenAI.
• Публичные API: При открытии API для публики ключи API предоставляют простой метод контроля доступа.
• Упрощенная настройка: Для быстрых и простых нужд аутентификации, особенно на начальной стадии разработки. В отличие от Logto M2M, ключи API не требуют предварительной регистрации клиента и не нуждаются в обмене на токен доступа. Вы просто передаете свой API-ключ как параметр в вашем запросе, и он просто работает.

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

• Действия, специфичные для пользователя: Когда приложению необходимо выполнить действия от имени пользователя.
• Точный контроль доступа (пользователь): Когда требуется точный контроль над действиями, которые может выполнять пользователь.

Logto Machine-to-Machine (Logto M2M)#

• Безопасность: Logto M2M идеально подходит для сценариев, где только доверенные клиенты имеют право на доступ к серверным услугам.
• Точный контроль доступа (клиент): Когда требуется точный контроль над действиями, которые может выполнять приложение.

Заключение#

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

Механизм Logto M2M позволяет пользователям устанавливать точный доступ к функциям RBAC (управление доступом на основе ролей). Мы также планируем поддерживать ключи API и PAT в ближайшем будущем. Следите за нашими обновлениями функций!