Jak testovat přihlášení přes 2FA, OAuth a sociální účty
Přihlášení přes SMS kód, autentizační aplikaci nebo sociální účet propojuje vaši aplikaci s dalším systémem. Jeden dlouhý end-to-end test proto bývá pomalý, citlivý na stav účtu a závislý na poskytovateli, kterého neovládáte. Spolehlivější strategie rozdělí otázky mezi několik vrstev a úplný průchod ponechá jen pro malý počet rozhodujících scénářů.
Proč se běžný test přihlášení zasekne
Dvoufaktorové ověření (2FA) vyžaduje po hesle další důkaz, například jednorázový kód nebo potvrzení v zařízení. Automatizace potřebuje bezpečný způsob, jak tento důkaz v testovacím prostředí získat. Čekání na osobní telefon člena týmu není opakovatelné a sdílený účet může při souběžných bězích měnit relaci, vyčerpat povolené pokusy nebo se zablokovat.
Při sociálním přihlášení uživatel navíc opustí vaši doménu a později se vrátí na návratovou, takzvanou callback adresu. OAuth 2.0 slouží k delegované autorizaci; identitu pro přihlášení nad ním často doplňuje OpenID Connect. Test nemusí znovu prověřovat vlastní přihlašovací stránku poskytovatele. Má ověřit, jak vaše aplikace tok zahájí, zpracuje návrat a vytvoří nebo odmítne relaci.
Rozdělte pokrytí do tří vrstev
1. Chování vlastní aplikace držte pod svou kontrolou. Ověřte nabídku způsobů přihlášení, validaci vstupů, chybové zprávy a výsledný stav uživatele. Řízenou odpovědí lze nasimulovat úspěch, odmítnutí souhlasu, chybějící údaje nebo výpadek poskytovatele. Takové testy jsou rychlé, samy však neprokazují reálné propojení.
2. Integraci kontrolujte v testovacím tenantu nebo režimu poskytovatele. Použijte samostatnou konfiguraci klienta, přesně určené návratové adresy a účty bez produkčních oprávnění. Zkontrolujte úspěšný návrat, zrušení uživatelem, odmítnutou či neplatnou odpověď, mapování identity a situaci, kdy stejný člověk již účet v aplikaci má. Konkrétní možnosti testování se liší a je nutné je ověřit v aktuální dokumentaci daného poskytovatele.
3. Jen několik end-to-end scénářů prochází celý tok. Reprezentativní kontrola může potvrdit, že prohlížeč přejde k poskytovateli a aplikace uživatele po návratu přihlásí ke správnému účtu. Širší kombinace rolí a chybových stavů patří do nižších vrstev. Pokud je externí přihlášení kritickou produkční cestou, lze jeho dostupnost po bezpečné přípravě sledovat podobně jako při monitoringu jiných externích integrací.
Jak pracovat s 2FA a relací
V neprodukčním prostředí připravte mechanismus určený pro testování: vyhrazenou schránku na jednorázové kódy, virtuální autentizátor nebo funkci podporovanou poskytovatelem. Musí být oddělený od produkce a dostupný pouze testovacímu procesu. Univerzální kód nebo tajná hlavička fungující v produkci by vytvořily bezpečnostní výjimku, nikoli bezpečnou testovatelnost.
Každý test nemusí opakovat celé přihlášení. Po samostatném ověření toku mohou ostatní scénáře začít s relací připravenou přes podporované API nebo uložený stav prohlížeče. Playwright popisuje opakované použití autentizovaného stavu, ale upozorňuje, že soubor může obsahovat citlivé cookies a hlavičky. Neukládejte jej do Gitu, omezte jeho platnost a pro paralelní běhy používejte oddělené účty.
Samostatně ověřte odhlášení, vypršení relace, odebrání přístupu, změnu role a otevření chráněné stránky po zániku relace. U 2FA doplňte scénáře pro chybný a expirovaný kód, opakované použití téhož kódu a překročení povoleného počtu pokusů podle pravidel produktu.
Na co si dát pozor
Testovací režim nesmí měnit produkční bezpečnostní pravidla. Současná doporučení pro návrh OAuth toků shrnuje OAuth 2.0 Security Best Current Practice. Funkční automatizace ale není bezpečnostní audit a nepotvrzuje odolnost proti všem útokům.
U testovacích účtů dokumentujte vlastníka, roli, způsob uložení tajných údajů i postup obnovy. Další technické předpoklady shrnuje článek o tom, jak připravit web na automatizované testy.
Co tím získáte
- Rychlejší běžné scénáře díky opakovanému použití bezpečně připravené relace.
- Oddělený důkaz o chování vlastní logiky a propojení s poskytovatelem.
- Menší riziko, že se testy navzájem zablokují přes sdílené účty nebo kódy.
- Jasnou hranici mezi funkční kontrolou a bezpečnostním posouzením.
Další krok
Nakreslete přihlašovací tok od prvního kliknutí po vznik relace a u každého kroku označte vlastníka systému. Rozhodněte, které odpovědi nasimulujete, které ověříte v testovacím režimu poskytovatele a který tok musí projít celý. Teprve stabilní kontroly zařaďte do vhodné fáze CI/CD.