Лучшие методы создания безопасных ключей API

1656529213 luchshie metody sozdaniya bezopasnyh klyuchej api

автор Рамеш Лингапа

1*-QHPiNtOHuhuD2B7SqMLPw

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

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

Сегодня существует несколько стандартов аутентификации, таких как ключи API, OAuth, JWT и т.д.

В этой статье мы рассмотрим, как правильно управлять ключами API для доступа к API.

Так почему ключи API?

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

Если вы предоставляете API для использования клиентов, вам важно создать его должным образом.

Давайте начнём, и я покажу вам, как правильно создать ключи API.

Генерация ключей API

Поскольку ключ API сам по себе является идентификатором приложения или пользователя, он должен быть уникальным, случайным и невозможным для угадывания. Создаваемые ключи API также должны использовать буквенно-цифровые и специальные символы. Примером такого ключа API является zaCELgL.0imfnc8mVLWwsAawjYr4Rx-Af50DDqtlx.

Безопасное хранилище ключей API

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

Подумай об этом. Причина, по которой нам нужно сохранять ключи API, состоит в том, чтобы убедиться, что ключ API в запросе действителен и выдан нами (как пароль).

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

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

В коде выше первичным ключом будет комбинация префикса и хеша ключа API {prefix}.{hash_of_whole_api_key}.

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

Представление ключа API пользователям

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

1*DutIyYh2hE-YAkirxtoIxg
Отображение сгенерированного ключа API с уведомлением

Как пользователи могут позже идентифицировать сгенерированный ключ API

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

Теперь вы можете хранить этот префикс в базе данных и отображать его на консоли, чтобы пользователи могли быстро определить правильную запись ключа API, например:

1*WU0mFXXFXW2VlA9BXK3ffA
Консоль управления ключами API

Не давайте ключу API все силы

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

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

Например,

  • если вам нужен ключ API, чтобы просто отправлять электронные письма, вы можете создать ключ API со сферой действия как «email.send»
  • если конечный пользователь имеет несколько серверов и каждый выполняет определенное действие, то можно создать отдельный ключ API с определенной сферой действия.

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

1*-HHZ-Vfwz9FBPl-FIlS6mg

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

1*y9SVyRJa3m50tQ0buEU1VA
Сущность базы данных API Key

Ключи API, ограничивающие скорость

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

Вывод

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

Счастливая защита ваших API!

Добавить комментарий

Ваш адрес email не будет опубликован.