Autentizace v API testech: klíče, tokeny, OAuth a expirace

První API test často funguje s tokenem ručně zkopírovaným z prohlížeče. Za hodinu vyprší, v CI není uživatelská relace a celá automatizace se zastaví ještě před první obchodní kontrolou. Autentizace proto nemůže zůstat jednorázovým setupem „nějak získej token“. Je samostatnou testovanou schopností s vlastními scénáři, tajemstvími a životním cyklem.

Tento článek se věnuje čistě API pohledu: jak klient prokáže identitu, jaká oprávnění credential nese a co se děje při expiraci či rotaci. Uživatelské obrazovky, přesměrování a chování formuláře rozebírá samostatně článek o testování přihlášení, 2FA a OAuth v UI.

Nejprve odlište autentizaci od autorizace

Autentizace odpovídá na otázku, kdo nebo co volá API. Autorizace rozhoduje, co tento klient smí udělat. Platný token proto ještě neznamená přístup ke každému endpointu.

Test musí umět rozlišit alespoň tyto stavy:

credential chybí nebo má neplatný formát;
podpis tokenu, issuer nebo audience nejsou důvěryhodné;
token byl platný, ale vypršel nebo byl odvolán;
identita je ověřena, ale chybí scope, role nebo vlastnictví konkrétního záznamu;
autentizace prošla a obchodní požadavek je chybný z jiného důvodu.

Podle HTTP Semantics v RFC 9110 odpověď 401 Unauthorized vyžaduje autentizační údaje a obsahuje výzvu WWW-Authenticate; 403 Forbidden znamená, že server požadavku rozuměl, ale odmítá jej splnit. Konkrétní API smlouva může záměrně skrýt existenci zdroje nebo omezit detail chyby, proto testujte dohodnuté chování, ne univerzální představu o každém systému.

Zmapujte všechny způsoby získání přístupu

Jedno API může současně používat více mechanismů:

API klíč pro serverovou integraci;
krátkodobý bearer access token pro uživatelská volání;
OAuth client credentials pro komunikaci služba–služba;
authorization code flow s PKCE pro veřejného klienta;
podepsaný požadavek, mTLS nebo interní workload identity;
samostatný refresh token pro získání nového access tokenu.

Pro každý mechanismus vytvořte matici: kdo credential vydává, komu je určen, kde se posílá, jakou má platnost, scopes, způsob obnovy, rotace a odvolání. Bez této mapy vzniknou testy, které používají administrátorský token na všechno a neprověří skutečné hranice oprávnění.

OAuth je rámec autorizace, ne jeden konkrétní typ přihlašování. RFC 6749 definuje role, access tokeny, scopes, expiraci a refresh tokeny. Aktuální bezpečnostní doporučení doplňuje OAuth 2.0 Security Best Current Practice, RFC 9700. Testovací návrh má vycházet z flow, který používá daný klient, ne z jednoho univerzálního skriptu.

Matici uložte společně s verzí API a konfigurací testovacího prostředí. Při změně issueru, audience nebo povoleného flow tak uvidíte, které scénáře je nutné upravit a která očekávání se nesmějí potichu změnit.

API klíče testujte jako identitu s životním cyklem

API klíč bývá jednodušší než OAuth token, ale není jen náhodný řetězec v hlavičce. Může identifikovat aplikaci, zákazníka nebo prostředí a nést limity či povolený rozsah operací.

Základní sada scénářů zahrnuje:

platný klíč na povoleném endpointu;
chybějící, prázdný, zkrácený a neznámý klíč;
klíč pro jiné prostředí nebo klienta;
klíč bez potřebného oprávnění;
deaktivovaný a nahrazený klíč;
přechodné období při rotaci, pokud současně platí starý i nový;
limit volání a způsob, jakým API vrátí informaci o překročení.

Klíč neposílejte v URL, pokud smlouva podporuje bezpečnější hlavičku. URL se může dostat do historie, proxy logů a analytiky. V testovacím kódu má být název tajemství, ne hodnota. Credential se vloží z chráněného úložiště konkrétního prostředí až při spuštění.

Rotaci je třeba otestovat bez poškození ostatních uživatelů testovacího prostředí. Nevypínejte sdílený klíč, který používá jiný tým. Bezpečnější je samostatný testovací klient nebo řízené administrační API s izolovaným rozsahem.

Bearer token není jen delší API klíč

Bearer token může použít kdokoli, kdo jej získá; samotné držení opravňuje k volání. RFC 6750 popisuje jeho použití v HTTP a bezpečnostní hrozby. Testovací logy, screenshoty a reporty proto nesmějí ukládat celou hodnotu tokenu.

U JWT bývá užitečné kontrolovat claims, ale test nemá tokenu věřit jen proto, že jej umí dekódovat. Dekódování Base64 není ověření podpisu. API má ověřit podpis a přijatelný algoritmus, issuer, audience, časové claims a podle smlouvy také scope či další omezení.

Negativní scénáře mohou použít token s:

změněným podpisem nebo obsahem;
nesprávným issuerem či audience;
chybějícím povinným claimem;
scope pro čtení při pokusu o zápis;
identitou jiného vlastníka zdroje;
časem exp v minulosti nebo nbf v budoucnosti;
nepodporovaným typem nebo algoritmem podle bezpečnostní politiky.

Takové tokeny vytvářejte pouze v testovacím identity provideru nebo pomocí testovacích klíčů. Soukromý podpisový klíč produkčního poskytovatele nemá být testovací sadě dostupný.

Expirace musí být test, ne občasný incident

Nejčastější chybou automatizace je token získaný jednou na začátku a sdílený všemi testy bez ohledu na platnost. Krátký lokální běh projde, paralelní nebo hodinová sada začne náhodně vracet 401.

Testovací klient má znát čas expirace a používat bezpečnou rezervu. Pokud token vyprší za 30 sekund, nemá s ním začínat dlouhou operaci. Zároveň se nesmí spoléhat pouze na lokální hodiny; mezi klientem a serverem může být malý clock skew, který smlouva řeší tolerancí.

Prověřujte minimálně:

volání těsně před dohodnutou expirací;
volání po expiraci bez obnovy;
automatické získání nového tokenu a opakování pouze bezpečné operace;
chování po odvolání stále časově platného tokenu, pokud systém podporuje revokaci;
dlouhý běh, během kterého token přirozeně expiruje;
paralelní požadavky, které současně zjistí potřebu obnovy.

Poslední bod často vytvoří refresh storm: dvacet workerů současně požádá o nový token. Pomáhá uzamčení obnovy a sdílená cache v rámci procesu, aby token obnovil jeden worker a ostatní použili nový výsledek. Cache ale musí být oddělena podle identity, audience a scope; jinak test omylem použije oprávnění jiného scénáře.

Refresh token potřebuje vlastní negativní scénáře

Refresh token má obvykle jinou citlivost a životnost než access token. API nebo autorizační server může při každé obnově vydat nový refresh token a předchozí zneplatnit. Test musí novou hodnotu uložit atomicky, jinak paralelní proces přepíše aktuální token starým.

Ověřte:

platnou obnovu a nové expires_in;
chybějící, chybný, expirovaný a odvolaný refresh token;
opětovné použití starého tokenu po rotaci;
změnu nebo zúžení scope podle podporované smlouvy;
chování při dočasné chybě autorizačního serveru;
zda se po odhlášení nebo zrušení přístupu další obnova zamítne.

Neopakujte automaticky každý obchodní požadavek po 401. U ne-idempotentní operace, například vytvoření platby, mohl server operaci provést a jen odpověď se ztratila. Klient potřebuje idempotency key nebo následné ověření stavu, ne slepý retry.

OAuth flow testujte odděleně od obchodního API

Když test selže při získání tokenu, ještě nic neřekl o objednávce. Rozdělte proto vrstvy:

malé kontraktní testy token endpointu a očekávaných chyb;
helper nebo „token factory“, který získá credential pro pojmenovanou identitu a scopes;
obchodní API testy, které dostanou připraveného klienta;
samostatné end-to-end testy celého flow tam, kde přesměrování a souhlas tvoří podstatnou část rizika.

Pro komunikaci služba–služba test client credentials nepoužívá uživatelské jméno a heslo. Pro veřejné aplikace se při authorization code flow používá PKCE podle návrhu systému. Staré návody s Resource Owner Password Credentials grantem nekopírujte do nové automatizace; RFC 9700 stanoví, že se tento grant nesmí používat.

Test token endpointu má zkontrolovat status, strukturu odpovědi, typ tokenu, dobu platnosti a povolené scopes bez zapisování hodnot do reportu. V produkci se aktivní negativní pokusy omezují podle bezpečnostní dohody; většina takových scénářů patří do izolovaného prostředí.

Scopes, role a vlastnictví dat tvoří matici

Jeden administrátorský token vytváří pohodlné, ale slabé testy. Každý důležitý endpoint potřebuje alespoň povolenou a zakázanou identitu. U objektové autorizace nestačí „běžný uživatel“: uživatel A má číst vlastní objednávku, ne objednávku uživatele B.

Praktická matice obsahuje řádky endpointů a sloupce identit nebo oprávnění. Pro každý průnik určí očekávané čtení, zápis a případné maskování polí. Zmenšená riziková matice je lepší než kombinatorické spuštění všech rolí nad vším.

U chybové odpovědi nekontrolujte pouze status. Ověřte, že nevydává citlivý detail, neprozrazuje existenci cizího zdroje nad rámec smlouvy a nezmění data. Autorizace musí platit také u hromadných endpointů, exportů a vnořených zdrojů, ne jen u jednoho GET /orders/{id}.

Mock identity provider nebo reálná služba

Mock poskytuje rychlé a deterministické scénáře: expiraci lze posunout bez čekání, vytvořit libovolný scope a simulovat chybu. Neověří však skutečné TLS, konfiguraci klienta, podporovaný flow, rotaci klíčů ani chování externího poskytovatele.

Užitečná je proto kombinace. Většina obchodních testů používá rychlý testovací issuer nebo připravené tokeny s kontrolovanými claims. Menší integrační sada pravidelně získává token od skutečně nakonfigurovaného poskytovatele v neprodukčním tenantu. Rozdíl mezi mockem, sandboxem a reálnou integrací popisuje článek mock, sandbox nebo reálná služba.

Tajemství a reporty jsou součástí testu

Client secret, API klíč a refresh token nepatří do repozitáře, testovacích dat ani parametru příkazového řádku viditelného v seznamu procesů. CI má číst tajemství z chráněného úložiště, omezit je na potřebné prostředí a maskovat výstup.

Maskování přesné hodnoty nestačí, pokud log vypíše celou hlavičku Authorization, URL s klíčem nebo JSON odpověď token endpointu. Před uložením logu je bezpečnější allowlist povolených hlaviček a polí než nekonečný seznam zakázaných názvů. Pro diagnostiku stačí hash nebo poslední čtyři znaky identifikátoru, issuer, audience, scope a čas expirace — ne credential.

Testovací účty mají mít minimální oprávnění, jasného vlastníka, automatizovanou rotaci a bezpečný způsob obnovy. Sdílený účet „admin test“ snižuje schopnost odhalit chyby autorizace a komplikuje audit.

Co spolehlivá autentizační vrstva přinese

Obchodní testy přestanou náhodně padat na expirovaném tokenu a zároveň nebudou ignorovat bezpečnostní hranice. Tým dokáže samostatně zjistit, zda selhal identity provider, získání credentialu, scope nebo samotná funkce API. Rotaci klíče lze nacvičit před produkční změnou a report poskytne diagnostiku bez úniku tajemství.

Autentizace je ale pouze jedna vrstva. Statusy, schéma, idempotence, chybové stavy a obchodní pravidla patří do širší strategie co testovat v API.

Další krok

Sepište pro jedno API matici identity, credentialu, scope, expirace a způsobu obnovy. Vytvořte centrálního testovacího klienta, který token bezpečně získá, cacheuje s rezervou a rediguje logy. Potom přidejte tři první negativní scénáře: chybějící credential, platná identita bez oprávnění a expirovaný token. Oddělíte tak chyby přístupu od chyb obchodní funkce a připravíte sadu na dlouhé i paralelní běhy.