Най-добри практики за изграждане на защитени 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. Надявам се това да ви помогне.

Честито осигуряване на вашите APIs!