Найкращі практики створення безпечних ключів API

Ми всі знаємо, наскільки цінними є API. Вони є шлюзом для вивчення інших послуг, інтеграції з ними та швидшого створення чудових рішень.

Можливо, ви створили або думаєте про створення API для використання іншими розробниками. API потребує певної форми автентифікації, щоб забезпечити авторизований доступ до даних, які він повертає.

Сьогодні доступно кілька стандартів автентифікації, такі як API Keys, 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 і безпечно зберегти його. Ви можете зробити щось подібне:

Як користувачі можуть пізніше ідентифікувати сформований ключ API

Інша проблема полягає в тому, як користувачі визначають правильний ключ API у вашій консолі, якщо їм потрібно редагувати або скасувати його. Це можна вирішити, додавши префікс до ключа API. Зверніть увагу на малюнку над першими 7 символами (це наш префікс), розділеними крапкою.

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

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

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

Право підходу є наданням кінцевих користувачів правильно обмежити доступ API Key і вибрати конкретні дії , які ключ API може виконувати. Це можна зробити, надавши сфери застосування , де кожна сфера представляє конкретний дозвіл.

Наприклад,

  • якщо вам потрібен ключ API, щоб просто надсилати електронні листи, ви можете сформувати ключ API із сферою дії як “email.send”
  • якщо кінцевий користувач має кілька серверів і кожен виконує певну дію, тоді може бути сформований окремий ключ API із певним обсягом.

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

Таким чином користувачі можуть генерувати кілька ключів API, кожен з яких має певні правила доступу для кращого захисту. І коли отримано запит на API, ви можете перевірити, чи має ключ API правильну область доступу до цього API. Тепер база даних виглядає приблизно так:

Клавіші обмеження швидкості API

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

Висновок

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

Щасливого захисту ваших API!