Jak přidat přihlášení do aplikace: hesla, magic linky, Google a role

Přihlášení do aplikace přidáte tak, že zvolíte způsob: e-mail a heslo, magic linky (jednorázový odkaz k přihlášení poslaný e-mailem), nebo „Přihlásit se přes Google“. Implementujte ho pomocí ověřené autentizační knihovny nebo hostované služby, ne od nuly. Pak rozhodněte, co smí každý typ uživatele dělat (role), a vynucujte to na serveru u každé stránky i každého požadavku na API. Relace by měly používat zabezpečené cookies, mít expiraci a při odhlášení skutečně skončit.

Tento průvodce prochází jednotlivé volby a detaily, které oddělují funkční přihlášení od bezpečného. Koncepty za tím vysvětluje článek co je autentizace.

Nejdřív rozhodněte: vůbec potřebujete přihlašování?

Přihlašování přidává tření a odpovědnost. Potřebujete ho, když:

• Uživatelé mají soukromá data (své rezervace, dokumenty, faktury)
• Uživatelé mohou měnit věci, které uvidí ostatní
• Přístup účtujete
• Různí lidé potřebují různá oprávnění (vlastník vs. personál vs. zákazník)

Přihlašování nepotřebujete u marketingového webu, veřejného adresáře nebo formuláře, který vám jen pošle e-mail. Čekací listina nepotřebuje účty; stačí pole pro e-mail.

Čtyři běžné způsoby přihlášení

Mnoho aplikací kombinuje dvě možnosti: přihlášení přes Google plus e-mailové magic linky je oblíbená dvojice, která pokryje většinu lidí bez ukládání jakýchkoli hesel.

E-mail a heslo

Pokud nabízíte hesla, tohle jsou nepodkročitelná minima:

• Hesla hashujte pomalým algoritmem pro hashování hesel. Doporučení OWASP pro ukládání hesel uvádí Argon2id, jako alternativy scrypt, bcrypt nebo PBKDF2. Hesla nikdy neukládejte v čitelné podobě ani pomocí rychlého obecného hashe.
• Resetování hesla používá náhodný odkaz s jednorázovým použitím, který vyprší a odesílá se na ověřený e-mail.
• Neprozrazujte, které e-maily mají účet. „Pokud je tento e-mail registrován, poslali jsme odkaz pro reset“ je lepší než „Účet nenalezen“.
• Omezte počet pokusů o přihlášení a reset, aby se zpomlilo hádání hesel.
• Povolte dlouhá hesla a správce hesel; zrušte pravidla, která vynucují podivné kombinace znaků.

Magic linky a jednorázové kódy

Magic link je odkaz k přihlášení poslaný uživateli e-mailem. Kliknutím se přihlásí. Jednorázový kód je stejná myšlenka, jen se přepisuje místo klikání.

• Odkazy a kódy rychle expirují a fungují jen jednou.
• Odkaz by měl přihlásit uživatele na zařízení, kde klikl, a token nesmí zůstat v logách ani v nástrojích analytiky.
• Potřebujete spolehlivé odesílání e-mailů; viz jak posílat e-maily z aplikace. Testujte v Gmailu a Outlooku a kontrolujte složky se spamem.

Přihlášení přes Google (a další OAuth poskytovatele)

„Přihlásit se přes Google“ používá OAuth a OpenID Connect: Google potvrdí, kdo uživatel je, a řekne vaší aplikaci jeho e-mail a jméno. Nastavení, stav k zářím 2026, probíhá v sekci Google Auth Platform v Google Cloud Console:

1. Vytvořte nebo vyberte projekt a vyplňte stránku Branding, tedy co uživatelé vidí na obrazovce souhlasu (název aplikace, e-mail podpory, logo).
2. Na stránce Clients vytvořte klienta typu „Web application“.
3. Přidejte authorized JavaScript origins a redirect URI, tedy přesné adresy, na kterých vaše aplikace běží a na které Google po přihlášení vrací uživatele.
4. Uložte client ID a client secret do tajných údajů aplikace.

Věci, které se běžně pokazí, podle dokumentace OAuth od Googlu:

• redirect_uri_mismatch: adresa pro přesměrování se musí shodovat přesně, včetně http vs. https, velkých písmen a koncového lomítka. Přidejte jednu pro náhledovou adresu a jednu pro živou doménu.
• Vyžaduje se HTTPS: redirect URI musí používat HTTPS, s výjimkou localhost během vývoje.
• Parametr state by se měl při návratu kontrolovat kvůli ochraně proti cross-site request forgery. Dobré knihovny to dělají za vás.

Pokud žádáte jen základní informace o přihlášení (jméno, e-mail, profil), Google uvádí, že ověření aplikace není povinné. Žádost o přístup k Gmailu, Disku nebo Kalendáři uživatelů je jiná a vyžaduje ověření.

Vlastní řešení, nebo poskytovatel?

Oba první dva přístupy jsou rozumné. Hostovaní poskytovatelé zvládnou víc za vás, ale přidávají závislost a někdy účtují za aktivního uživatele; aktuální ceny si ověřte na jejich webech. Knihovny drží všechno ve vaší databázi, ale více konfigurace nechávají na vás. Ať zvolíte cokoli, požádejte AI, aby použila to, a nevytvářela vlastní logiku hesel nebo relací.

Role a oprávnění

Přihlášení vám řekne, kdo někdo je. Oprávnění rozhodují, co smí dělat. Zpočátku držte jednoduchost:

Pravidla, která jsou důležitější než názvy rolí:

• Kontrolujte na serveru, pokaždé. Skrytí tlačítka na stránce nezabrání tomu, aby někdo volal API přímo.
• Omezujte podle vlastníka. Člen, který načte „rezervace 123“, ji dostane jen tehdy, když je jeho.
• Uživatelé se nemohou sami povýšit. Při úpravách profilu ignorujte pole s rolí poslaná z prohlížeče.
• Výchozí stav je bez přístupu. Nové trasy by měly vyžadovat přihlášení, pokud nerozhodnete jinak.

Otestujte to se dvěma účty: přihlaste se jako jeden, poznamenejte si ID záznamu, pak se přihlaste jako druhý a zkuste ho otevřít. Náš bezpečnostní checklist obsahuje úplný test.

Bezpečnost relací

Po přihlášení si aplikace uživatele pamatuje pomocí relace, obvykle v cookie. Doporučení OWASP pro správu relací:

• Cookies relace nastavené s Secure (jen HTTPS), HttpOnly (nečitelné skripty stránky) a SameSite
• Nové ID relace při přihlášení a znovu při změně oprávnění
• Časový limit nečinnosti i maximální absolutní délka, vynucené na serveru
• Odhlášení, které ukončí relaci na serveru, ne jen smaže cookie
• Relace zneplatněné při změně hesla uživatele

Ukládání přihlašovacích tokenů do localStorage prohlížeče je v návodech běžné, ale vystavuje je každému skriptu běžícímu na stránce; zabezpečené cookies bývají pro webové aplikace lepší výchozí volbou.

Prompt, který pokryje podstatné

Přidej do této aplikace uživatelské účty. Uživatelé se mohou registrovat a přihlásit e-mailem a heslem, nebo přes Google. Použij [knihovnu nebo poskytovatele] místo vlastního kódu pro autentizaci. Hesla hashuj pomocí Argon2id nebo bcrypt. Přidej reset hesla e-mailem s jednorázovým odkazem, který vyprší za hodinu. Relace drž v zabezpečených cookies s HttpOnly. Chraň /dashboard a každou trasu /api, aby je mohli používat jen přihlášení uživatelé, a zajisti, aby uživatelé viděli jen své vlastní projekty. Přidej roli „admin“, která vidí všechny uživatele; na /admin se smí dostat jen administrátoři, kontrolováno na serveru.

Pak otestujte: zaregistrujte se, odhlaste se, přihlaste se, resetujte heslo, zkuste privátní URL bez přihlášení a zkuste záznam jiného uživatele.

Časté chyby u přihlašování postaveného pomocí AI

• Ochrana jen na stránce. Stránka přesměruje odhlášené uživatele, ale API vrací data komukoli.
• Tajné údaje v prohlížeči. Client secret OAuth a administrátorské klíče poskytovatele patří na server.
• Záměna náhledu a živé adresy. Redirect URI Googlu nebo odkaz v e-mailu pro reset ukazuje na náhled, takže přihlášení se po publikování rozbije.
• Chybějící ověření e-mailu. Kdokoli se může zaregistrovat jako anyone@company.com. Před uložením oprávnění vázaného na adresu ověřte e-mail.
• Testování jen šťastné cesty. Zkuste špatná hesla, expirované odkazy a druhý účet.

Přidání přihlášení v Mythexu

V Mythexu je přihlášení pro uživatele vaší aplikace něco, co přidáváte do své aplikace; je oddělené od vašeho vlastního účtu Mythex. Mythex nenabízí vestavěný produkt pro autentizaci, takže přinesete vlastní autentizační knihovnu nebo poskytovatele a jejich klíče:

1. Zvolte přístup, například e-mail a heslo uložené ve vaší vlastní databázi, nebo SDK hostovaného poskytovatele.
2. Pokud uživatele ukládáte sami, aplikace potřebuje databázi; požádejte o ni v chatu nebo použijte /database.
3. Klíče poskytovatele uložte do tajných údajů projektu (/secrets nebo nastavení projektu).
4. Použijte prompt podobný tomu výše a otestujte v náhledu. Pro přihlášení přes Google přidejte redirect URI pro náhled i pro publikovanou adresu.

Viz Přidání přihlášení do aplikace v dokumentaci. Pokud stavíte placený produkt, jak postavit SaaS MVP vysvětluje účty a fakturaci dohromady.

Otázky