Autentizace v aplikaci: SSO, dvoufázové ověření a správa uživatelů

01Oddělte identitu, oprávnění a přihlášenou relaci

Autentizace ověřuje, pod jakým účtem člověk jedná. Autorizace rozhoduje, co smí udělat. Relace udržuje stav přihlášení mezi požadavky. Tyto části potřebují společný návrh, ale každou musíte samostatně ověřit. Zelené potvrzení přihlášení nedokazuje právo stáhnout konkrétní fakturu.

Před výběrem služby sepište skupiny uživatelů: zaměstnance, zákazníky, externisty, správce a technické integrace. U každé určete, kdo účet zakládá, ke které organizaci patří a kdo schvaluje jeho práva. Lidský účet a automatická integrace mají odlišný životní cyklus; sdílené heslo správce pro obojí je neudržitelný základ.

02SSO řeší společné přihlášení, ne všechny přístupy

SSO umožňuje využít přihlášení u poskytovatele identity pro více aplikací. Firma tak může soustředit pravidla ověřování a část správy účtů na jedno místo. Aplikace však dál odpovídá za přiřazení uživatele ke správné organizaci a za své vlastní operace.

OpenID Connect přidává identitní vrstvu nad OAuth 2.0. OAuth samotný řeší delegované oprávnění, není úplným protokolem pro přihlášení. SAML je další způsob federovaného přihlášení, se kterým se setkáte zejména v podnikových integracích.

Nechte si potvrdit podporované protokoly skutečného zákaznického prostředí. U firemního portálu je důležité také to, kdo smí připojit další organizaci a jak se prokáže její oprávnění. Samotná znalost názvu firmy nebo e-mailové domény nemá stačit k převzetí správy.

03Integrujte ověřenou knihovnu a kontrolujte výsledek

Vlastní implementace protokolu přidává prostor pro chyby. Po dodavateli chtějte udržovanou knihovnu a popis ověřování přijatých odpovědí. Pro OAuth vychází aktuální bezpečnostní doporučení z RFC 9700, včetně ochrany toku pomocí PKCE a kontroly přesměrování. Přihlašovací token nepatří automaticky do role přístupového tokenu pro libovolné API.

V zadání požadujte negativní testy: cizí vydavatel, špatný příjemce, prošlá platnost, jiné přesměrování a chybné přiřazení organizace. Uživatel se nemá propojit s existujícím účtem jen proto, že dva zdroje vrátily stejný e-mail. Stanovte důvěryhodné podmínky propojení a nabídněte bezpečné řešení konfliktu.

04MFA vybírejte podle hrozeb a obnovy

Dvě hesla nejsou dva různé faktory. Kombinace se opírá například o znalost a držení prostředku. NIST rozlišuje i odolnost vůči phishingu: ručně opisované jednorázové kódy ji samy neposkytují. Proto nehodnoťte metody jen podle počtu kroků na obrazovce.

Passkeys používají kryptografické klíče a jsou navázané na konkrétní službu; princip vysvětluje FIDO Alliance. Mohou být synchronizované mezi zařízeními nebo vázané na konkrétní prostředek. Vyberte podporované varianty podle citlivosti účtu, zařízení uživatelů a požadované obnovy.

Pro administrátory navrhněte silnější požadavky než pro čtení veřejných informací. U změny fakturačních údajů, přidání správce nebo výměny ověřovacího prostředku zvažte nové ověření. Nechte si předvést také uživatele bez chytrého telefonu, výměnu zařízení a ztrátu všech běžných prostředků.

Samostatný návod k organizaci zavádění najdete v článku MFA a passkeys ve firmě. Zde řešíme hlavně chování vaší aplikace a návaznost přihlášení na konkrétní oprávnění.

05Heslo a obnova účtu nesmějí být slabou objížďkou

Pokud hesla zůstávají, umožněte správce hesel, omezujte pokusy a kontrolujte známá kompromitovaná hesla. Bezpečné ukládání patří do prověřeného řešení, ne do vlastního šifrovacího nápadu. OWASP spojuje přihlašování také s ochranou citlivých změn a opětovným ověřením.

Doporučení OWASP pro obnovu hesla zahrnují jednorázové časově omezené tokeny a odpovědi, které zbytečně neprozrazují existenci účtu. Do návrhu přidejte upozornění na změnu a pravidla pro již otevřené relace. Obnova MFA potřebuje stejnou pozornost jako obnova hesla.

Podpora musí mít jasný postup: jak ověří žadatele, kdo schvaluje výjimku a co zaznamená. Naléhavý telefonát od údajného ředitele nemá automaticky vypnout ochranu. U důležitých účtů předem dohodněte druhého schvalovatele a bezpečný náhradní přístup. Tyto situace cvičte s testovacím účtem.

06Role navrhněte jako konkrétní pracovní oprávnění

Začněte maticí operací: zobrazit zakázku, upravit ji, schválit slevu, exportovat data, spravovat uživatele. Sloupec „správce“ bez dalšího rozlišení postupně pohltí vše. RBAC přiřazuje oprávnění rolím; někdy potřebujete navíc podmínku vlastnictví záznamu, organizace nebo limitu částky.

OWASP doporučuje nejmenší potřebná oprávnění a kontrolu každého požadavku. Skrytí tlačítka není bezpečnostní kontrola. Server musí odmítnout nepovolenou operaci i tehdy, když někdo požadavek odešle mimo vaše rozhraní.

Jde o ilustrační matici. Upravte ji podle odpovědností a testujte i jejich kombinace. Pokud člověk přepne mezi dvěma organizacemi, zkontrolujte vyhledávání, exporty, přílohy i odkazy ve zprávách. Oddělení musí platit mimo hlavní seznam záznamů.

07Po odhlášení a odebrání práv musí změna skutečně platit

U relací požadujte bezpečné cookie, přiměřenou expiraci a možnost serverového zneplatnění. OWASP popisuje ochranu relací včetně atributů Secure, HttpOnly a SameSite. Samotné tyto atributy nenahrazují celý návrh ochrany proti podvrženým požadavkům.

Ptejte se na rozdíl mezi odhlášením z aplikace, odhlášením u poskytovatele identity a zrušením všech zařízení. U tokenů zjistěte, jak dlouho mohou po odebrání oprávnění zůstat použitelné. Zapište přijatelnou prodlevu a ověřte ji měřením, včetně otevřeného prohlížeče a mobilního klienta.

08Spravujte nástup, změnu role a odchod

Účet má vlastníka, důvod a případně datum konce. Při nástupu schvalte správnou organizaci a minimální práva. Při změně pozice stará oprávnění odeberte, nestačí přidat nová. Při odchodu řešte i relace, API klíče, sdílené odkazy a předání rozpracovaných úkolů.

SCIM standardizuje správu uživatelů a skupin mezi systémy. Přesto ověřte, co konkrétní integrace udělá po deaktivaci: zda pouze zabrání dalšímu přihlášení, nebo ovlivní i existující přístup. Technické napojení není důkazem dokončeného odchodu.

09Co převzít před spuštěním

• Schválenou matici rolí a testy zakázaných operací.
• Přihlášení přes skutečného poskytovatele identity a zpracování jeho výpadku.
• Obnovu účtu, změnu e-mailu a výměnu ověřovacího prostředku.
• Odhlášení, odebrání práv a ukončení účtu v otevřených relacích.
• Audit změn rolí a obnovy bez hesel, tokenů a dalších tajemství v záznamech.
• Vlastníka aktualizací, incidentů a pravidelných revizí oprávnění.

U každého testu evidujte verzi, účet, očekávaný výsledek a skutečný výsledek. Přejímací protokol má doložit chování, nikoli jen zaškrtnutou položku „SSO hotovo“. Největší přínos má test, který odhalí rozdíl mezi přihlášeným uživatelem a oprávněným uživatelem.

10Spravovaná služba, nebo vlastní provoz

Spravovaný poskytovatel identity může převzít aktualizace a provoz přihlašovací infrastruktury. Vaše firma však dál vlastní pravidla účtů, integraci a reakci na incident. U vlastního provozu navíc potřebujete lidi, kteří zvládnou aktualizace, obnovu, dostupnost a správu klíčů. Porovnejte skutečné rozdělení práce, ne jen cenu licence.

Do nabídky napište počet aktivních uživatelů, firemních organizací a požadovaných SSO připojení. Zjistěte, zda jsou auditní záznamy, automatická správa účtů, náhradní metody a export zahrnuté v konkrétním tarifu. Vyžádejte postup odchodu od poskytovatele: co převedete, jak připojíte nové ověřovací prostředky a kdo pomůže s migrací.

11Přechod na nové přihlášení připravte bez ztráty účtů

Nejdřív vytvořte mapu stávajících identit. Jedna osoba může mít více účtů, změněný e-mail a členství ve více firmách. Použijte stabilní interní identifikátor; změna e-mailu nemá vytvořit jiného vlastníka objednávek. U každého nejasného propojení určete kontrolovaný postup, místo aby migrace automaticky sloučila záznamy.

1. V testovací kopii ověřte účty, členství a všechny role bez živých tajemství.
2. Vyberte pilotní skupinu včetně správce, externisty a člověka ve dvou organizacích.
3. Vyzkoušejte nové přihlášení, obnovu i přístup ze staré otevřené relace.
4. Naplánujte podporu, informaci pro uživatele a postup při výpadku.
5. Po přechodu odeberte staré cesty podle schváleného plánu a prověřte záznamy.

Záložní cesta potřebuje datum ukončení a vlastníka. Jinak zůstane staré přihlášení bez MFA trvalou výjimkou. Návrat při poruše nesmí znamenat plošné vypnutí ochrany. Předem určete, které účty mohou nouzově pracovat, za jakých podmínek a s jakým dohledem.

12Modelový test odchodu správce zákazníka

Představte si správce firmy A, který je zároveň běžným členem firmy B. Po odchodu z A mu odeberete pouze toto členství. Aplikace má zachovat jeho oprávněnou práci pro B, ale odmítnout export A, starý přímý odkaz na přílohu i změnu členů A. Testujte každou cestu samostatně.

Potom účet deaktivujte úplně. Ověřte otevřený prohlížeč, jiné zařízení i případné osobní API klíče. Záznam má ukázat, kdo změnu provedl a kdy začala platit. Toto je ilustrační přejímací scénář, nikoli tvrzení o testu konkrétního produktu. Pomáhá odhalit chybu, kterou běžný pokus o nové přihlášení neukáže.

13Časté otázky k autentizaci

Připravujete nový portál nebo měníte přihlašování? V rámci vývoje webových aplikací s vámi projdeme identity, role a přejímací scénáře. Začněte seznamem lidí, organizací a operací, které musí aplikace bezpečně rozlišit.