Autentifikácia v API testoch: kľúče, tokeny, OAuth a expirácia

Prvý API test často funguje s tokenom ručne skopírovaným z prehliadača. O hodinu vyprší, v CI nie je používateľská relácia a celá automatizácia sa zastaví ešte pred prvou obchodnou kontrolou. Autentifikácia preto nemôže zostať jednorazovým setupom „nejako získaj token“. Je samostatnou testovanou schopnosťou s vlastnými scenármi, tajomstvami a životným cyklom.

Tento článok sa venuje čisto API pohľadu: ako klient preukáže identitu, aké oprávnenia nesie credential a čo sa deje pri expirácii či rotácii. Používateľské obrazovky, presmerovania a správanie formulára rozoberá osobitne článok o testovaní prihlásenia, 2FA a OAuth v UI.

Najprv odlíšte autentifikáciu od autorizácie

Autentifikácia odpovedá na otázku, kto alebo čo volá API. Autorizácia rozhoduje, čo tento klient smie urobiť. Platný token preto ešte neznamená prístup ku každému endpointu.

Test musí vedieť rozlíšiť aspoň tieto stavy:

credential chýba alebo má neplatný formát;
podpis tokenu, issuer alebo audience nie sú dôveryhodné;
token bol platný, ale vypršal alebo bol odvolaný;
identita je overená, no chýba scope, rola alebo vlastníctvo konkrétneho záznamu;
autentifikácia prešla a obchodná požiadavka je chybná z iného dôvodu.

Podľa HTTP Semantics v RFC 9110 odpoveď 401 Unauthorized vyžaduje autentifikačné údaje a obsahuje výzvu WWW-Authenticate; 403 Forbidden znamená, že server požiadavke rozumel, ale odmieta ju splniť. Konkrétna API zmluva môže zámerne skryť existenciu zdroja alebo obmedziť detail chyby, preto testujte dohodnuté správanie, nie univerzálnu predstavu o každom systéme.

Zmapujte všetky spôsoby získania prístupu

Jedno API môže súčasne používať viac mechanizmov:

API kľúč pre serverovú integráciu;
krátkodobý bearer access token pre používateľské volania;
OAuth client credentials pre komunikáciu služba–služba;
authorization code flow s PKCE pre verejného klienta;
podpísanú požiadavku, mTLS alebo internú workload identity;
samostatný refresh token na získanie nového access tokenu.

Pre každý mechanizmus vytvorte maticu: kto credential vydáva, komu je určený, kde sa posiela, akú má platnosť, scopes, spôsob obnovy, rotácie a odvolania. Bez tejto mapy vzniknú testy, ktoré používajú administrátorský token na všetko a nepreveria reálne hranice oprávnení.

OAuth je rámec autorizácie, nie jeden konkrétny typ prihlasovania. RFC 6749 definuje roly, access tokeny, scopes, expiráciu a refresh tokeny. Aktuálne bezpečnostné odporúčania dopĺňa OAuth 2.0 Security Best Current Practice, RFC 9700. Testovací návrh má vychádzať z flow, ktorý používa daný klient, nie z jedného univerzálneho skriptu.

Maticu uložte spolu s verziou API a konfiguráciou testovacieho prostredia. Pri zmene issueru, audience alebo povoleného flow tak vidíte, ktoré scenáre treba upraviť a ktoré očakávania sa nesmú potichu zmeniť.

API kľúče testujte ako identitu s životným cyklom

API kľúč býva jednoduchší než OAuth token, ale nie je iba náhodný reťazec v hlavičke. Môže identifikovať aplikáciu, zákazníka alebo prostredie a niesť limity či povolený rozsah operácií.

Základná sada scenárov zahŕňa:

platný kľúč na povolenom endpointe;
chýbajúci, prázdny, skrátený a neznámy kľúč;
kľúč pre iné prostredie alebo klienta;
kľúč bez potrebného oprávnenia;
deaktivovaný a nahradený kľúč;
prechodné obdobie pri rotácii, ak súčasne platí starý aj nový;
limit volaní a spôsob, akým API vráti informáciu o prekročení.

Kľúč neposielajte v URL, ak zmluva podporuje bezpečnejšiu hlavičku. URL sa môže dostať do histórie, proxy logov a analytiky. V testovacom kóde má byť názov tajomstva, nie hodnota. Credential sa vloží z chráneného úložiska konkrétneho prostredia až pri spustení.

Rotáciu treba otestovať bez poškodenia ostatných používateľov testovacieho prostredia. Nevypínajte zdieľaný kľúč, ktorý používa iný tím. Bezpečnejší je samostatný testovací klient alebo riadené administračné API s izolovaným rozsahom.

Bearer token nie je len dlhší API kľúč

Bearer token môže použiť ktokoľvek, kto ho získa; samotné držanie oprávňuje na volanie. RFC 6750 opisuje jeho použitie v HTTP a bezpečnostné hrozby. Testovacie logy, screenshoty a reporty preto nesmú ukladať celú hodnotu tokenu.

Pri JWT býva užitočné kontrolovať claims, ale test nemá veriť tokenu iba preto, že ho vie dekódovať. Dekódovanie Base64 nie je overenie podpisu. API má overiť podpis a prijateľný algoritmus, issuer, audience, časové claims a podľa zmluvy aj scope či ďalšie obmedzenia.

Negatívne scenáre môžu použiť token s:

zmeneným podpisom alebo obsahom;
nesprávnym issuerom či audience;
chýbajúcim povinným claimom;
scope pre čítanie pri pokuse o zápis;
identitou iného vlastníka zdroja;
časom exp v minulosti alebo nbf v budúcnosti;
nepodporovaným typom alebo algoritmom podľa bezpečnostnej politiky.

Takéto tokeny vytvárajte iba v testovacom identity provideri alebo pomocou testovacích kľúčov. Súkromný podpisový kľúč produkčného poskytovateľa nemá byť dostupný testovacej sade.

Expirácia musí byť test, nie občasný incident

Najčastejšia chyba automatizácie je token získaný raz na začiatku a zdieľaný všetkými testami bez ohľadu na jeho platnosť. Krátky lokálny beh prejde, paralelná alebo hodinová sada začne náhodne vracať 401.

Testovací klient má poznať čas expirácie a používať bezpečnú rezervu. Ak token vyprší o 30 sekúnd, nemá s ním začať dlhú operáciu. Zároveň sa nesmie spoliehať iba na lokálne hodiny; medzi klientom a serverom môže byť malý clock skew, ktorý zmluva rieši toleranciou.

Preverujte minimálne:

volanie tesne pred dohodnutou expiráciou;
volanie po expirácii bez obnovy;
automatické získanie nového tokenu a opakovanie iba bezpečnej operácie;
správanie po odvolaní ešte časovo platného tokenu, ak systém podporuje revokáciu;
dlhý beh, počas ktorého token prirodzene expiruje;
paralelné požiadavky, ktoré naraz zistia potrebu obnovy.

Posledný bod často vytvorí refresh storm: dvadsať workerov súčasne požiada o nový token. Pomáha uzamknutie obnovy a zdieľaná cache v rámci procesu, aby token obnovil jeden worker a ostatní použili nový výsledok. Cache však musí byť oddelená podľa identity, audience a scope; inak test omylom použije oprávnenie iného scenára.

Refresh token potrebuje vlastné negatívne scenáre

Refresh token má zvyčajne inú citlivosť a životnosť než access token. API alebo autorizačný server môže pri každej obnove vydať nový refresh token a predchádzajúci zneplatniť. Test musí uložiť novú hodnotu atomicky, inak paralelný proces prepíše aktuálny token starým.

Overte:

platnú obnovu a nové expires_in;
chýbajúci, chybný, expirovaný a odvolaný refresh token;
opätovné použitie starého tokenu po rotácii;
zmenu alebo zúženie scope podľa podporovanej zmluvy;
správanie pri dočasnej chybe autorizačného servera;
či sa po odhlásení alebo zrušení prístupu ďalšia obnova zamietne.

Neopakujte automaticky každú obchodnú požiadavku po 401. Pri ne-idempotentnej operácii, napríklad vytvorení platby, mohol server operáciu vykonať a iba odpoveď sa stratila. Klient potrebuje idempotency key alebo následné overenie stavu, nie slepý retry.

OAuth flow testujte oddelene od obchodného API

Keď test zlyhá pri získaní tokenu, ešte nič nepovedal o objednávke. Rozdeľte preto vrstvy:

malé kontraktné testy token endpointu a očakávaných chýb;
helper alebo „token factory“, ktorý získa credential pre pomenovanú identitu a scopes;
obchodné API testy, ktoré dostanú pripraveného klienta;
samostatné end-to-end testy celého flow tam, kde presmerovanie a súhlas tvoria podstatnú časť rizika.

Pre komunikáciu služba–služba test client credentials nepoužíva používateľské meno a heslo. Pre verejné aplikácie sa pri authorization code flow používa PKCE podľa návrhu systému. Staré návody s Resource Owner Password Credentials grantom nekopírujte do novej automatizácie; RFC 9700 stanovuje, že tento grant sa nesmie používať.

Test token endpointu má skontrolovať status, štruktúru odpovede, typ tokenu, čas platnosti a povolené scopes bez zapisovania hodnôt do reportu. V produkcii sa aktívne negatívne pokusy obmedzujú podľa bezpečnostnej dohody; väčšina takýchto scenárov patrí do izolovaného prostredia.

Scopes, roly a vlastníctvo dát tvoria maticu

Jeden administrátorský token vytvára pohodlné, ale slabé testy. Každý dôležitý endpoint potrebuje aspoň povolenú a zakázanú identitu. Pri objektovej autorizácii nestačí „bežný používateľ“: používateľ A má čítať vlastnú objednávku, nie objednávku používateľa B.

Praktická matica obsahuje riadky endpointov a stĺpce identít alebo oprávnení. Pre každý prienik určí očakávané čítanie, zápis a prípadné maskovanie polí. Zmenšená riziková matica je lepšia než kombinatorické spustenie všetkých rolí nad všetkým.

Pri chybovej odpovedi nekontrolujte iba status. Overte, že nevydáva citlivý detail, neprezrádza existenciu cudzieho zdroja nad rámec zmluvy a nezmení dáta. Autorizácia musí platiť aj pri hromadných endpointoch, exportoch a vnorených zdrojoch, nielen pri jednom GET /orders/{id}.

Mock identity provider alebo reálna služba

Mock poskytuje rýchle a deterministické scenáre: expiráciu možno posunúť bez čakania, vytvoriť ľubovoľný scope a simulovať chybu. Neoverí však skutočné TLS, konfiguráciu klienta, podporovaný flow, rotáciu kľúčov ani správanie externého poskytovateľa.

Preto je užitočná kombinácia. Väčšina obchodných testov používa rýchly testovací issuer alebo pripravené tokeny s kontrolovanými claims. Menšia integračná sada pravidelne získava token od reálne nakonfigurovaného poskytovateľa v neprodukčnom tenante. Rozdiel medzi mockom, sandboxom a reálnou integráciou rozoberá článok mock, sandbox alebo reálna služba.

Tajomstvá a reporty sú súčasť testu

Client secret, API kľúč a refresh token nepatria do repozitára, testovacích dát ani parametra príkazového riadka viditeľného v zozname procesov. CI má čítať tajomstvo z chráneného úložiska, obmedziť ho na potrebné prostredie a maskovať výstup.

Maskovanie presnej hodnoty nestačí, ak log vypíše celú hlavičku Authorization, URL s kľúčom alebo JSON odpoveď token endpointu. Pred uložením logu je bezpečnejší allowlist povolených hlavičiek a polí než nekonečný zoznam zakázaných názvov. Pri diagnostike stačí hash alebo posledné štyri znaky identifikátora, issuer, audience, scope a čas expirácie — nie credential.

Testovacie účty majú mať minimálne oprávnenia, jasného vlastníka, automatizovanú rotáciu a bezpečný spôsob obnovy. Zdieľaný „admin test“ účet znižuje schopnosť odhaliť chyby autorizácie a komplikuje audit.

Čo spoľahlivá autentifikačná vrstva prinesie

Obchodné testy prestanú náhodne padať na expirovanom tokene a zároveň nebudú ignorovať bezpečnostné hranice. Tím dokáže samostatne zistiť, či zlyhal identity provider, získanie credentialu, scope alebo samotná funkcia API. Rotácia kľúča sa dá nacvičiť pred produkčnou zmenou a report poskytne diagnostiku bez úniku tajomstva.

Autentifikácia je však iba jedna vrstva. Statusy, schéma, idempotencia, chybové stavy a obchodné pravidlá patria do širšej stratégie čo testovať na API.

Ďalší krok

Spíšte pre jedno API maticu identity, credentialu, scope, expirácie a spôsobu obnovy. Vytvorte centrálneho testovacieho klienta, ktorý token bezpečne získa, cacheuje s rezervou a rediguje logy. Potom pridajte tri prvé negatívne scenáre: chýbajúci credential, platná identita bez oprávnenia a expirovaný token. Tým oddelíte chyby prístupu od chýb obchodnej funkcie a pripravíte sadu na dlhé aj paralelné behy.