Passkeys vo webovej aplikácii: prihlásenie bez hesla a obnova účtu

Passkeys (po slovensky aj prístupové kľúče) umožňujú prihlásenie bez hesla do webovej aplikácie. Používateľ prihlásenie potvrdí odtlačkom prsta, tvárou alebo PIN kódom svojho zariadenia a server si namiesto hesla uloží verejný kľúč. Pre firmu s klientskym portálom alebo internou aplikáciou je hlavným prínosom ochrana pred phishingom, nie iba pohodlie.

Samotné tlačidlo „Vytvoriť passkey“ však nestačí. O výsledku rozhoduje správne zvolená doména, bezpečná registrácia, správa zariadení a najmä obnova účtu, ktorá nesmie zostať najslabším miestom. Nižšie nájdete ilustračný príklad, postup zavedenia, rozhodovaciu tabuľku, časté chyby a kontrolný zoznam.

Čo passkeys riešia a čo nie

Passkey je pár kryptografických kľúčov. Súkromný kľúč zostáva u správcu passkeys používateľa, teda v telefóne, počítači, správcovi hesiel alebo v hardvérovom bezpečnostnom kľúči. Vaša aplikácia si uloží verejný kľúč. Pri prihlásení zariadenie podpíše výzvu servera až po potvrdení používateľom, zvyčajne odomknutím zariadenia. Technický základ tvorí štandard W3C Web Authentication (WebAuthn) Level 3, ktorý je od 25. augusta 2026 odporúčaním W3C.

Kľúčovým prínosom je odolnosť proti phishingu. Podľa štandardu WebAuthn sa passkey dá použiť len pre tú istú stranu (RP ID, zvyčajne doménu), pre ktorú bol zaregistrovaný. Dokumentácia Google pre vývojárov dodáva, že používateľa nemožno zmanipulovať k prihláseniu na podvodnej stránke, pretože overenie zabezpečuje prehliadač alebo operačný systém.

Americká smernica NIST SP 800-63B výslovne uvádza, že metódy, pri ktorých používateľ ručne prepisuje kód, napríklad jednorazové kódy z SMS alebo z aplikácie, nie sú odolné proti phishingu: podvodná stránka môže kód preposlať skutočnej službe. WebAuthn naopak uvádza ako príklad štandardu odolného proti phishingu. Slovenskej firme táto smernica nič neukladá, je však dobre zdokumentovanou referenciou.

Passkeys nevyriešia zle nastavené oprávnenia po prihlásení, ukradnutú reláciu ani slabú obnovu účtu. Ak útočník presvedčí podporu, aby mu „obnovila prístup“, kryptografia nepomôže. Preto obnove venujeme samostatnú časť.

Synchronizované a na zariadenie viazané passkeys

WebAuthn rozlišuje dva typy prihlasovacích údajov. Ich vlastnosti priamo ovplyvňujú, ako navrhnete obnovu účtu.

Typ	Ako sa správa	Dôsledok pre aplikáciu
Synchronizovaný passkey (multi-device credential)	Správca passkeys ho môže zálohovať a sprístupniť na ďalších zariadeniach používateľa.	Strata jedného zariadenia zvyčajne neznamená stratu prístupu. Na najvyššej úrovni NIST AAL3 sa však synchronizované autentifikátory používať nesmú.
Passkey viazaný na zariadenie (single-device credential)	Nikdy sa nezálohuje, napríklad passkey uložený v hardvérovom bezpečnostnom kľúči.	Podľa WebAuthn neodolá strate zariadenia, preto má mať účet ďalší autentifikátor alebo proces obnovy.

Aplikácia typ rozpozná podľa príznakov BE (backup eligibility) a BS (backup state) v údajoch, ktoré vráti zariadenie. Štandard WebAuthn odporúča ukladať ich posledné hodnoty pri účte. Keď sa BS zmení z 1 na 0, passkey už nie je zálohovaný a aplikácia by mala používateľa previesť overením ostatných spôsobov prihlásenia, prípadne pridaním ďalšieho.

Príklad: passkeys v B2B portáli distribútora

Ilustračný príklad, nie skutočný klient. Distribútor prevádzkuje portál na adrese portal.example.com, kde odberatelia zadávajú objednávky a sťahujú faktúry. Zamestnanci pracujú v administrácii na admin.example.com. Dnes sa všetci prihlasujú heslom a pri citlivých akciách kódom z SMS.

Zavedenie by mohlo prebehnúť v troch fázach:

Ponuka po prihlásení. Po prihlásení a overení e-mailom portál ponúkne vytvorenie passkey. Heslo zatiaľ zostáva ako záloha.
Passkey ako predvolená voľba. Prihlasovací formulár ponúkne uložený passkey priamo v návrhoch prehliadača. Kto passkey nemá, prihlási sa po starom.
Povinné pre správcov. Zamestnanci s prístupom k cenníkom a údajom odberateľov musia mať dva registrované autentifikátory, napríklad passkey v notebooku a hardvérový kľúč uložený v trezore.

Ak majú passkeys fungovať na oboch subdoménach, distribútor nastaví RP ID na example.com. Návod web.dev uvádza, že pri RP ID example.com sa používateľ môže prihlásiť na login.example.com aj na ďalších subdoménach example.com. Ak sú portál a administrácia oddelené systémy s rôznymi účtami, môžu mať naopak samostatné RP ID.

Postup zavedenia v ôsmich krokoch

Zmapujte vstupy a skupiny používateľov. Spíšte všetky cesty k účtu: prihlasovací formulár, mobilnú aplikáciu, zabudnuté heslo, zmenu e-mailu aj podporu. Pri každej skupine určte, či bude passkey voliteľný, odporúčaný alebo povinný.
Zvoľte RP ID pred prvou registráciou. Podľa WebAuthn je predvoleným RP ID doména stránky; nastaviť ho možno aj na jej registrovateľnú nadradenú doménu. Passkey funguje len s RP ID, pre ktoré vznikol, takže po neskoršej zmene si ho používatelia musia vytvoriť znova.
Pred vytvorením passkey overte používateľa silnejšie než heslom. web.dev odporúča overenie napríklad e-mailom alebo telefónom v krátkom časovom okne a varuje pred overením iba heslom: s uniknutým heslom by si útočník vytvoril vlastný passkey. Zoznam už registrovaných passkeys posielajte v parametri excludeCredentials, aby nevznikali duplicity.
Na serveri použite overenú knižnicu. web.dev odporúča spracovať odpoveď prehliadača serverovou knižnicou, nie vlastným kódom. Uložte ID prihlasovacieho údaja, verejný kľúč, ID používateľa, AAGUID (identifikátor správcu passkeys, podľa ktorého passkey pomenujete), príznaky BE a BS a dátum vytvorenia a posledného použitia. Do user.id nevkladajte osobné údaje, napríklad e-mail.
Ponuku zobrazte len tam, kde funguje. Metódou PublicKeyCredential.getClientCapabilities() zistíte, či zariadenie podporuje passkeys aj ich ponuku priamo v prihlasovacom formulári. Pri citlivých operáciách kontrolujte príznak UV, pretože pri nastavení userVerification: "preferred" môže zariadenie overenie používateľa vynechať.
Posielajte notifikácie. Po pridaní passkey pošlite používateľovi e-mail. Podľa web.dev zostáva passkey, ktorý si útočník vytvorí bez vedomia používateľa, použiteľný aj po zmene hesla; notifikácia pomôže takýto prístup odhaliť.
Pridajte stránku na správu passkeys. Používateľ má vidieť názov, dátum vytvorenia, posledné použitie a to, či je passkey synchronizovaný, a vedieť ho hneď odstrániť. NIST vyžaduje, aby sa autentifikátor dal zneplatniť okamžite po nahlásení straty alebo krádeže.
Spustite pilot a vyhodnoťte ho. Začnite menšou skupinou používateľov. Sledujte úspešnosť registrácií, chyby pri prihlásení, počet obnov účtu a požiadavky na podporu. Až potom urobte z passkey predvolenú voľbu.

Obnova účtu: najslabšie miesto, ak ho nenavrhnete

Ak sa dá passkey obísť odkazom „zabudnuté heslo“ alebo jediným kódom z SMS, bezpečnosť účtu je len taká silná ako táto cesta. NIST SP 800-63B rozlišuje štyri triedy obnovy: uložené obnovovacie kódy, zaslané obnovovacie kódy, kontakty na obnovu a opakované overenie identity. Iný postup, napríklad cez pracovníka podpory, pripúšťa len na základe analýzy rizík a so zdokumentovaním.

Viac spôsobov prihlásenia už vopred

NIST odporúča viesť používateľov k tomu, aby mali aspoň dva samostatné spôsoby autentifikácie, a vyžaduje, aby sa k účtu dalo pripojiť viac autentifikátorov. Najlepšia obnova je tá, ktorú netreba použiť: druhý passkey na inom zariadení alebo hardvérový kľúč.

Obnovovacie kódy

Uložený obnovovací kód má podľa NIST obsahovať aspoň 64 bitov z náhodného generátora, ukladá sa iba ako hash, jeho overovanie je obmedzené počtom pokusov a po použití sa kód zneplatní a vydá sa nový. Kód zaslaný e-mailom smie platiť najviac 24 hodín, cez SMS alebo hlasový hovor najviac 10 minút. Pri účtoch na úrovni AAL2 vyžaduje NIST dva kódy získané rôznymi spôsobmi, jeden kód spolu s overením iným autentifikátorom pripojeným k účtu, alebo opakované overenie identity, ak bola identita pôvodne overená.

Podpora a notifikácie

Každá obnova účtu musí podľa NIST vyvolať notifikáciu používateľovi. Pre podporu pripravte písaný postup: čo overí, kto schvaľuje výnimky a čo sa zapisuje do auditnej stopy. Bez neho je ručná obnova miestom, kde sociálne inžinierstvo obíde aj tú najlepšiu technológiu.

Rozhodovacia tabuľka podľa skupiny používateľov

Skupina	Odporúčaný prístup	Obnova účtu	Pozor na
Zákazníci portálu alebo e-shopu s nízkym rizikom	Passkey ako voliteľná možnosť popri doterajšom prihlásení, ponuka po prihlásení	Kód zaslaný e-mailom s krátkou platnosťou a uložený obnovovací kód	Nezhoršiť prihlásenie tým, ktorí passkey nechcú
B2B odberatelia s prístupom k faktúram a objednávkam	Passkey odporúčaný, aspoň dva spôsoby prihlásenia, opätovné overenie pri citlivých akciách	Dva nezávislé spôsoby obnovy a notifikácia o každej obnove	Zdieľané firemné účty – každá osoba má mať vlastný účet
Správcovia a zamestnanci s prístupom k údajom	Passkey povinný; kde to vyžadujú interné pravidlá, hardvérové kľúče viazané na zariadenie	Druhý registrovaný kľúč a zdokumentovaný postup cez určenú osobu	Ak požadujete úroveň NIST AAL3, synchronizované passkeys nestačia

Tabuľka vyjadruje naše odporúčanie, nie normu. Hranice medzi skupinami nastavte podľa toho, aké údaje a akcie sú za prihlásením.

Výhody a kompromisy

Menšia škoda pri úniku databázy. Pri účtoch s passkey server uchováva verejný kľúč namiesto hesla. Google uvádza, že útočník tak získa oveľa menej hodnotné údaje a po incidente je menej upratovania.
Menej SMS kódov. Podľa Google môžu passkeys odstrániť potrebu jednorazových kódov z SMS alebo aplikácie pri prihlásení, čo šetrí aj náklady na SMS.
Kompromis: záložné heslo. Kým heslo zostáva ako alternatíva, phishing naň stále funguje. Súčasťou zavedenia má byť plán, kedy a komu heslo odstránite.
Kompromis: závislosť od správcu passkeys. Synchronizované passkeys spravuje služba používateľa, napríklad cloudový účet alebo správca hesiel. Ochrana tejto zálohy je mimo vašej aplikácie.
Kompromis: viac práce v prevádzke. Pribudne registrácia, správa zariadení, notifikácie a nový postup obnovy. Podpora potrebuje návod skôr, než prídu prvé otázky.

Časté chyby

Vytvorenie passkey po zadaní samotného hesla bez ďalšieho overenia.
Chýbajúca notifikácia o novom passkey alebo o obnove účtu.
Obnova jediným kódom z SMS, ktorá obíde passkeys aj ostatné zabezpečenie.
RP ID zvolené narýchlo, napríklad len pre www, a neskôr zmenené.
Osobné údaje v user.id.
Používateľ nemá kde passkeys vidieť ani odstrániť.
Vlastné overovanie podpisov namiesto overenej knižnice.

Kontrolný zoznam pred spustením

RP ID je rozhodnuté a otestované na všetkých doménach, kde sa používatelia prihlasujú.
Pred registráciou passkey prebehne overenie silnejšie než heslo.
Server ukladá ID prihlasovacieho údaja, verejný kľúč, AAGUID, príznaky BE a BS a dátumy použitia.
Používateľ dostane notifikáciu o novom passkey aj o každej obnove účtu.
Stránka na správu passkeys umožňuje okamžité odstránenie.
Každý účet s passkey viazaným na zariadenie má druhý autentifikátor alebo obnovu.
Obnovovacie kódy sú jednorazové, uložené ako hash a chránené obmedzením pokusov.
Podpora má písaný postup obnovy a auditnú stopu.

Časté otázky

Môžeme heslá úplne zrušiť?

Áno, ale postupne. WebAuthn uvádza, že keď sa passkey stane zálohovaným (príznak BS sa zmení z 0 na 1), aplikácia môže používateľovi ponúknuť odstránenie hesla. Odporúčame to robiť až vtedy, keď má používateľ aspoň dva spôsoby prihlásenia a funkčnú obnovu účtu.

Čo ak používateľ stratí telefón?

Synchronizovaný passkey býva dostupný aj na jeho ďalších zariadeniach, takže sa prihlási napríklad z notebooku. Pri podozrení na zneužitie passkey v aplikácii odstráni a vytvorí nový. Passkey viazaný na zariadenie sa stratí spolu so zariadením, preto WebAuthn odporúča mať pri účte ďalší autentifikátor alebo proces obnovy.

Ukladá aplikácia odtlačky prstov alebo snímky tváre?

Nie. Odomknutie odtlačkom, tvárou alebo PIN kódom prebieha v zariadení používateľa a podľa Google si server ukladá verejný kľúč. Zoznam údajov, ktoré odporúča ukladať web.dev, biometrické údaje neobsahuje.

Stačí ako alternatíva jednorazový kód z SMS?

Proti phishingu nechráni: NIST jednorazové kódy, ktoré používateľ prepisuje, nepovažuje za odolné proti phishingu, pretože ich podvodná stránka môže preposlať. Ak SMS použijete pri obnove účtu, NIST obmedzuje platnosť zaslaného kódu na 10 minút. Pri citlivých účtoch odporúčame passkey ako hlavnú metódu a SMS nanajvýš ako jednu z ciest obnovy.

Ako vám pomôžeme

Passkeys sa dajú doplniť aj do existujúcej aplikácie, bez prepisovania celého systému. V rámci vývoja webových aplikácií na mieru navrhneme a implementujeme registráciu, prihlásenie, správu passkeys aj obnovu účtu a pripravíme postup pre podporu. Ďalšie praktické návody nájdete na našom blogu.

Zvažujete prihlásenie bez hesla v zákazníckom portáli alebo internej aplikácii? Napíšte nám a spoločne prejdeme, kde začať a čo pripraviť.

Zdroje

Web Authentication: An API for accessing Public Key Credentials – Level 3 – W3C, odporúčanie z 25. augusta 2026.
NIST Special Publication 800-63B – smernica NIST pre autentifikáciu a správu autentifikátorov, súčasť revízie SP 800-63-4.
Create a passkey for passwordless logins – web.dev, aktualizované 9. apríla 2026.
Passkeys – Google for Developers.