Сигурност на API за CTO: идентичност, gateway и токени, без сляпо доверие

Често срещана днес архитектура за сигурност на API има три части: доставчик на идентичност, който издава токените —Keycloak, Microsoft Entra ID, Okta или друг—, gateway, който приема целия трафик —APISIX, Kong, Apigee, Azure API Management или друг— и OAuth 2.0 като език, на който се искат и се представят права. Това е добра архитектура. Проблемът се появява при въпросите, които никой не е записал при проектирането ѝ: услугата зад gateway-а проверява ли токена отново? Какво става, когато едно API извиква друго? Ако потребителят излезе от сесията, токенът му спира ли да върши работа? Колко дълго трябва да живее един токен?

Тази статия отговаря на тези въпроси за онзи, който трябва да подпише архитектурата: CTO на банка, финтех, застрахователна компания, търговска верига или всяка друга регулирана компания. Всеки отговор идва със своето условие, защото в сигурността почти никога няма «винаги».

Три вида маршрут, три нива на доверие

Преди да се заговори за токени, е добре да се класифицира всеки маршрут на API:

API ключът идентифицира, но не упълномощава добре: не носи фини права, нито към кого е адресиран, нито стандартен срок на валидност, нито делегиране [1][2]. Служи за просто ползване, измерване и квоти. За интеграция между компании (B2B) с чувствителни данни е подходящ OAuth 2.0 с идентификационни данни на клиента (client credentials): системата на партньора получава по API токен с кратък живот, с ограничени права и адресиран до Вашето API [3][4]. Този път е подходящ, когато системата действа от свое име или по предварително споразумение; той не замества съгласието на човек. Ако запазите API ключове: по един на потребител и на среда, съхранявани като тайна, ротирани и никога в URL адреса, защото URL адресите остават записани в дневниците на gateway-а, на прокситата и на инструментите за мониторинг, където всеки с достъп може да ги прочете [2].

Трябва ли услугата зад gateway-а да проверява токена?

Това е въпросът, който предизвиква най-много спорове, и краткият отговор е: това, че е зад gateway-а, само по себе си не дава доверие. Така гласи рамката за нулево доверие на NIST: местоположението в мрежата не предполага доверие, а зоната на имплицитно доверие трябва да е възможно най-малка [5].

Пълният отговор разделя две неща, които често се бъркат:

• Валидиране на токена (автентичен ли е, издаден ли е от моя доставчик, за мен ли е, още ли е валиден?).
• Упълномощаване на операцията (може ли този човек или тази система да чете тази сметка, тази полица, тази поръчка?).

Второто, фината авторизация върху обекта, трябва да се оценява там, където са налични бизнес правилото и връзката с обекта: обикновено в услугата или в компонент за политики, вграден в нея. Gateway-ът може да допълни с груби контроли, но не замества това правило. Общо право като «четене на плащания» не решава дали някой може да прочете плащането на друг клиент. Тази грешка си има име и е първата в списъка на OWASP с рискове за API [6][7].

Първото може да се делегира на gateway-а, но само ако са изпълнени всички тези условия [5][8][9]:

1. Услугата не е достижима по никакъв друг път освен през gateway-а: нито от друга мрежа, нито от друга съседна услуга, нито по административен маршрут.
2. Каналът между gateway-а и услугата е автентикиран, например с взаимен TLS.
3. Gateway-ът изтрива всеки HTTP хедър за идентичност, дошъл отвън, и поставя свой, подписан (например вътрешен токен) или по автентикиран канал, така че услугата да може да провери, че идва от gateway-а.
4. Конфигурацията на маршрутите е инвентаризирана, тества се и при грешка затваря: маршрут без правило не остава отворен.

Ако някое условие не е изпълнено, документирайте друга точка за прилагане на политиката, която проверимо валидира идентичността на извикващия и контекста; ако няма такава, услугата трябва да го направи. И има случаи, в които е добре да го валидира, дори да са изпълнени и четирите: когато работи с пари или лични данни, когато решава въз основа на данни от токена или когато обслужва няколко клиенти или домейна.

Един конфигурационен детайл, който струва злато: при някои gateway-и плъгините, които валидират API ключове или JWT, препращат оригиналните идентификационни данни към услугата отзад, освен ако не се конфигурира иначе, а плъгинът за OpenID Connect при bearer_only със стойност false не изисква строго bearer токен [10][11]. Това са стойностите, документирани в APISIX 3.19 [доставчик]; потвърдете инсталираната версия и действителната конфигурация. Прегледът на тези стойности по подразбиране е част от архитектурата, а не дреболия.

Когато едно API извиква друго

Вътре в архитектурата една услуга трябва да извика друга. Има пет често срещани модела и всеки служи за нещо различно [12][13][14]:

Правило, което намалява риска от неправомерно повторно използване: всяка услуга проверява, че токенът е бил адресиран до нея. Полето, което го казва, се нарича аудитория (aud), и ако услугата не е в него, токенът се отхвърля [15][16]; за да се ограничи целта при поискването му, има индикатори на ресурса (RFC 8707) [30]. Така се избягва грешката «сляпо препращане» (token passthrough) и най-известната ѝ последица, confused deputy: услуга, която с чужд токен прави нещо, което потребителят никога не е упълномощавал. Например услуга за отчети, която получава токен, издаден за услугата за плащания, и с него успява да изпълнява плащания.

За веригата «A извиква B от името на потребителя» препоръчваният модел е обменът на токени: A сменя получения токен с нов, адресиран до B и с по-малко права [12]. В Keycloak стандартната функция V2 е включена по подразбиране, но клиентът, който я иска, трябва да е конфиденциален и да има включен Standard token exchange; стандартният обмен действа между клиенти от същия realm [17]. А NIST предлага нещо подобно за микроуслуги: смяна на външния токен на входа с вътрешен с кратък живот и проверка на всеки хоп [8].

Да се доверим на токена или да попитаме доставчика?

Има два начина да се разбере дали един токен е добър:

Локалната валидация не е само «подписът мина»: трябва да се фиксира очакваният издател, да се приемат само предвидените алгоритми, да се проверяват аудитория, срок на валидност и права и да се вземат ключовете от надеждно място, защото доставчикът ги ротира: услугата държи публичните ключове в кеш и, когато пристигне токен, подписан с непознат ключ, ги иска отново, вместо да го отхвърли или да го приеме на сляпо [18][19]. И една цена, която CTO подписва: при интроспекция на всяка заявка доставчикът на идентичност попада в критичния път на всички операции; ако падне или се забави, пада или се забавя всичко. А ако резултатът от интроспекцията се държи в кеш, времето на кеша не може да бъде по-голямо от прозореца за отмяна, който бизнесът приема: кеш от пет минути противоречи на обещание за «незабавна» отмяна.

Излизането от сесията не изключва вече издадените токени

Оперативен ефект със съществено значение, който често изненадва един комитет по сигурност: когато потребителят излезе от сесията, access токенът, който вече има, остава валиден до изтичането си, за всяка услуга, която го валидира локално. Механизмите за излизане от сесия на OpenID Connect прекратяват сесията и уведомяват приложенията, но не обезсилват access токените, които вече циркулират [20][21]; документацията на Keycloak предупреждава за това изрично [17].

Затова валидността се проектира на слоеве:

1. Кратки access токени, за да е малък прозорецът на експозиция.
2. Refresh токени с възможност за отмяна, свързани с клиента и, при публични приложения, с ротация [3].
3. Интроспекция при операциите, при които текущото състояние има значение: преводи, промени на бенефициент, масови изтегляния, административни действия.
4. Отмяна (RFC 7009), когато доставчикът я поддържа [22].
5. Събития за отмяна между системите (OpenID CAEP), които вече са окончателен стандарт; поддръжката им при доставчиците все още е неравномерна [23].

Колко дълго трябва да живее един токен?

В никоя норма не съществува «стандартна» продължителност. OAuth оставя живота на токена на доставчика [4]; стандартът за bearer токени препоръчва един час или по-малко [24]; а профилът за сигурност на отворното банкиране (FAPI 2.0) изисква кратки токени, без да фиксира цифра [25]. Има обаче начални диапазони за проектиране —редакционен критерий, а не норма—; нагласете ги според експозицията, прозореца за отмяна, повторната автентикация и наличността на доставчика:

Фабричните стойности на Keycloak [доставчик] са в тази посока. Проверихме ги директно в изходния му код (основният клон, консултиран на 6 октомври 2026 г.), защото документацията не ги публикува пълно [26]. Това са числа на доставчика и могат да се променят между версиите:

В Keycloak refresh токенът на нормална сесия живее колкото сесията позволява. Преди да се доверите на тези числа, прегледайте тези на Вашата инсталация: настройките по клиент и импортираните конфигурации ги променят.

Кога е нужен OpenID Connect?

• OAuth 2.0 е достатъчен, когато това, което се защитава, е достъпът на приложение или система до API: интеграции между компании, вътрешни процеси, права по обхват [4].
• OpenID Connect е подходящ, когато приложението се нуждае от автентикирана оперативно съвместима идентичност, claims за автентикация или единен вход (също ниво на автентикация, излизане от сесия и повторна автентикация за чувствителни действия) [27]. OAuth сам по себе си не стандартизира тази идентичност: OpenID Connect е слоят на идентичността върху OAuth.
• Честа грешка: ползването на ID токена на OpenID Connect за извикване на API. ID токенът е за приложението, което е започнало сесията; към API се изпраща access токенът [27].

При отвореното банкиране летвата се вдига

Ако Вашето API попада в света на отвореното банкиране или на финансовите данни, профилът FAPI 2.0 (окончателен стандарт) вдига летвата: токени, свързани с онзи, който ги ползва —с взаимен TLS или DPoP—, силна автентикация на клиента и защитени параметри на заявката [25][28][29]. Не е задължителен за всички API, нито сам по себе си е мексиканско задължение: може да бъде полезна техническа референция за API с висока стойност, когато приложимата рамка, договор или политиката за риска го възприемат, и не замества оценката на приложимите регулаторни задължения.

От къде да започнете

1. Класифицирайте маршрутите си в публични, с API ключ и с токен и проверете дали всеки е там, където трябва.
2. Решете, услуга по услуга, кой валидира токена, с четирите условия по-горе, записани на хартия.
3. Проверявайте аудиторията във всяка услуга и премахнете сляпото препращане на токени.
4. Прегледайте стойностите по подразбиране на Вашия доставчик на идентичност и на Вашия gateway.
5. Определете прозореца си за отмяна по вид операция и нагласете продължителностите и интроспекцията според него.

Колко от Вашите маршрути биха издържали днес такава проверка? Първият разговор за диагностика е безплатен: излизате с картата на маршрутите си по ниво на доверие и със слабите места, които да се адресират първи. Пишете ни в WhatsApp.