Jan Mikoláš
Slovník pojmů
Autentizace
Autentizace odpovídá na otázku „kdo to je?“. Je nezbytná pro přihlášení do aplikace, ale bez následné serverové autorizace sama neuděluje přístup k objednávce, účtu ani administraci.
Stručná definice
Ověření identity není rozhodnutí o oprávnění.
Při autentizaci subjekt prokáže něco, co zná, vlastní nebo čím je: například heslo, passkey, jednorázový kód, hardwarový klíč nebo kryptografický podpis služby. Aplikace důkaz ověří a podle výsledku vytvoří přihlášenou session nebo vydá omezený access token. Citlivější operace mohou vyžadovat opětovné ověření či více faktorů.
Autentizace neznamená, že je subjekt automaticky oprávněný k dané akci. Přihlášený skladník a správce účtů mohou být oba úspěšně autentizováni, ale nemají stejné pravomoci. Na každém relevantním serverovém endpointu proto následuje autorizace nad požadovaným zdrojem, rolí, tenantem a aktuálním kontextem.
K čemu slouží
Při vstupu uživatele i při komunikaci služeb
Ověření identity se netýká jen formuláře s heslem. Potřebují je browserové aplikace, API i automatizované integrační procesy.
- přihlášení zákazníka do účtu nebo operátora do e-shopové administrace
- vícefaktorové ověření před změnou platebních údajů, hesla nebo role
- single sign-on přes poskytovatele identity pomocí OpenID Connect
- ověření strojového klienta přístupovým tokenem, klientským certifikátem nebo jiným spravovaným credentialem
- opětovné ověření identity u rizikové operace nebo po dlouhé nečinnosti relace
Praktický příklad
Přihlášení operátora před prací s objednávkami
Aplikace načte účet podle přihlašovacího jména a ověří předložené heslo proti bezpečně uloženému hashovanému heslu. Při neúspěchu vrátí obecnou chybu a použije omezení pokusů, aby nezjednodušovala hádání účtů. Při úspěchu vytvoří novou relaci s rotovaným identifikátorem; heslo ani jeho hash se do session neukládají.
Ukázka znázorňuje pouze kritickou podmínku. V reálné aplikaci jí předchází validace vstupu, rate limiting a jednotná odpověď pro neexistující účet. Po založení relace každou další změnu objednávky stále ověřuje autorizace na serveru.
if (!password_verify($submittedPassword, $account->passwordHash)) {
throw new AuthenticationFailed();
}
session_regenerate_id(true); // až po úspěšném ověření
$_SESSION['account_id'] = $account->id;Jak funguje
Od předložení důkazu po ověřený subjekt
Dobře navržený tok odděluje ověření identity, vydání credentialu pro další request a následnou kontrolu oprávnění.
- Subjekt se identifikuje Předá uživatelské jméno, e-mail, identitu od poskytovatele nebo identifikátor strojového klienta. Identifikace ještě není důkaz.
- Předloží přihlašovací faktor Může jít o heslo, passkey, OTP nebo podpis. Výběr faktoru odpovídá hodnotě účtu a riziku operace.
- Server důkaz ověří Heslo se porovnává s hashovanou hodnotou, token s očekávanými vlastnostmi a externí identita s ověřeným protokolem. Selhání se omezuje a zaznamenává přiměřeně riziku.
- Vznikne session nebo token Server vytvoří odvolatelnou session nebo vydá omezený credential pro další komunikaci. Jeho životnost a ochrana se navrhují samostatně.
- Server autorizuje každý přístup Ověřená identita se propojí s aktuálními rolemi, vlastnictvím a politikou nad konkrétním zdrojem. Nejde o jednorázový krok UI.
Hlavní části
Důkaz identity, ochrana credentialu a řízení rizika
Bezpečná autentizace je sled kroků. Žádná jednotlivá knihovna nevyřeší slabé heslo, únik session ani příliš široké oprávnění.
Hesla a hashování
Heslo se neukládá v čitelné podobě ani se „nešifruje pro pozdější přečtení“. Server ukládá vhodný adaptivní hash a při ověření používá bezpečnou knihovní funkci.
Vícefaktorové ověření
Kombinuje nezávislé druhy důkazu, například heslo a passkey či jednorázový kód. Je zvlášť důležité pro administrátory a vysoce citlivé změny.
Rate limiting a detekce
Omezení pokusů, bezpečný recovery tok a monitoring chrání proti hádání credentialů. Nemá ale bezdůvodně zablokovat legitimní uživatele.
Reautentizace
Riziková operace může chtít čerstvý důkaz identity i během platné session, například před změnou hesla nebo výplatních údajů.
Strojová identita
Integrace nemá sdílet lidské heslo. Používá vlastní credential, úzké scope, rotaci tajemství a dohledatelného vlastníka.
Vztah k jiným přístupům
Session, JWT a externí login jsou prostředky, ne náhrada pravidel
Jejich vhodnost určuje typ klienta, možnost odvolání, citlivost dat a hranice mezi službami.
- Session
- Server po přihlášení drží stav a může jej ihned zneplatnit. Browser obvykle nese jen session ID v cookie.
- JWT
- Podepsaný token není automaticky důkaz bezpečného loginu. Příjemce musí ověřit podpis, časová tvrzení, publikum a zvolit plán pro odvolání.
- OpenID Connect
- Přidává nad OAuth 2.0 standardní identity vrstvu. Aplikace i tak ověřuje očekávaného poskytovatele, tok a platnost odpovědi.
- Autorizace
- Rozhoduje o akci nad zdrojem. Například platná session neznamená oprávnění zrušit libovolnou objednávku.
Výhody a omezení
Silnější přihlášení zmenšuje riziko, neodstraňuje potřebu návrhu
Přínosy
- přiřadí request konkrétnímu uživateli nebo službě pro další bezpečnostní rozhodnutí
- MFA a reautentizace snižují dopad odcizeného či uhádnutého hesla
- oddělené credentialy pro lidi a služby zlepšují revokaci i audit
- session nebo token lze omezit dobou, účelem a rozsahem použití
Rizika a časté chyby
- zaměnit úspěšné přihlášení za oprávnění pracovat s každým zdrojem
- ukládat hesla čitelně, vracet příliš přesné login chyby nebo vynechat ochranu proti hádání
- považovat podepsaný JWT za bezpečný bez ověření jeho kontextu a životnosti
- spoléhat na schování tlačítka ve frontendu místo serverové autorizace
Kdy ji navrhnout pečlivěji
Síla ověření odpovídá hodnotě účtu a konkrétní akci
Běžný zákaznický účet, interní administrace a partnerské API mají odlišné hrozby a potřeby. Administrace objednávek či uživatelských rolí si zpravidla zaslouží MFA, bezpečné obnovení přístupu, řízení session a audit. Automatizovaná integrace zase potřebuje vlastní credential s minimálními oprávněními, ne sdílený účet zaměstnance.
Výběr mezi cookie session, bearer tokenem a externím poskytovatelem identity není volba jedné univerzálně nejlepší technologie. Podstatné je, aby aplikace rozuměla způsobu předání credentialu, uměla jej zneplatnit nebo omezit a na všech vstupních cestách provedla serverovou autorizaci.
Na co myslet
Ověřovat na serveru, předcházet útokům a chránit další relaci
Bezpečný login tok se testuje i v chybových a obnovovacích stavech, ne jen pozitivním testem formuláře.
- ukládat hesla pomocí vhodného adaptivního hashe a nevypisovat jejich hodnoty do logů či chyb
- používat MFA nebo čerstvé ověření pro citlivé účty a operace podle rizika
- omezovat pokusy, bezpečně navrhnout obnovu hesla a vracet přiměřeně obecné chyby
- po úspěchu chránit session či token, rotovat session ID a nastavit dobu platnosti
- testovat, že po autentizaci server stále odmítne akci bez potřebného oprávnění
Časté otázky
Autentizace v praxi
Jaký je rozdíl mezi autentizací a autorizací?
Autentizace ověřuje identitu: kdo request poslal. Autorizace rozhoduje, zda tento subjekt smí danou operaci provést nad konkrétním zdrojem.
Je JWT autentizace?
JWT je formát tokenu. Může nést tvrzení vytvořená po autentizaci, ale sám nevysvětluje, jak byla identita ověřena ani nezaručuje správnou autorizaci.
Je OAuth 2.0 totéž co přihlášení?
Ne nutně. OAuth 2.0 řeší delegované oprávnění. Pro standardní ověření identity se nad ním obvykle používá OpenID Connect.
Stačí silné heslo?
Silné heslo je jen jeden faktor. U citlivých účtů pomáhá MFA, omezení pokusů, bezpečný recovery tok a ochrana následné session.
Jak řeším backend v praxi
Přístup navrhuji od identity až po konkrétní akci nad daty.
V API, e-commerce a interních systémech propojuji ověření identity se správou relací, rolemi a serverovou kontrolou zdrojů.