Hogyan adj bejelentkezést az appodhoz: jelszavak, mágikus linkek, Google és szerepkörök

Bejelentkezés hozzáadásához válassz egy módszert – e-mail és jelszó, mágikus linkek (egyszer használható bejelentkezési link e-mailben) vagy „Bejelentkezés Google-lal” –, és ezt egy bevált hitelesítési könyvtárral vagy hosztolt szolgáltatóval valósítsd meg, ne nulláról. Ezután döntsd el, mit tehet az egyes felhasználótípus (szerepkörök), és ezt a szerveren érvényesítsd minden oldalon és API-kérésnél. A munkamenetek biztonságos sütiket használjanak, lejárjanak, és kijelentkezéskor megfelelően véget érjenek.

Ez az útmutató végigveszi az egyes döntéseket, és azokat a részleteket, amelyek egy működő bejelentkezést biztonságossá tesznek. A mögötte álló fogalmakért lásd: mi az a hitelesítés.

Előbb döntsd el: kell-e egyáltalán bejelentkezés?

A bejelentkezés súrlódást és felelősséget jelent. Akkor van rá szükséged, ha:

• A felhasználóknak privát adataik vannak (foglalásaik, dokumentumaik, számláik)
• A felhasználók olyan dolgokat változtathatnak, amit mások látnak
• Hozzáférésért díjat kérsz
• Különböző embereknek különböző jogosultságok kellenek (tulajdonos, munkatárs, vásárló)

Lehet, hogy nincs rá szükséged egy marketingoldalnál, egy nyilvános könyvtárnál vagy egy olyan űrlapnál, amely csak e-mailt küld neked. Egy várólistához nem kellenek fiókok; egy e-mail mező elég.

A négy gyakori bejelentkezési módszer

Sok app kettőt kombinál: a Google-os bejelentkezés plusz e-mailes mágikus link népszerű páros, amely a legtöbb embert lefedi úgy, hogy nem tárol jelszavakat.

E-mail és jelszó

Ha jelszavakat kínálsz, ezek a nem alkuképes pontok:

• Hash-eld a jelszavakat egy lassú jelszó-hash algoritmussal. Az OWASP jelszótárolási útmutatója az Argon2id-t ajánlja, alternatívaként a scryptet, a bcryptet vagy a PBKDF2-t. Soha ne tárolj jelszavakat egyszerű szövegként vagy gyors általános hash-sel.
• A jelszó-visszaállítás egy véletlenszerű, egyszer használható, lejáró linket használjon, amelyet az ellenőrzött e-mail-címre küldesz.
• Ne áruld el, mely e-mailekhez tartozik fiók. A „Ha ez az e-mail regisztrálva van, elküldtünk egy visszaállító linket” jobb, mint a „Nem találtunk fiókot”.
• Korlátozd a sebességet a bejelentkezési és visszaállítási kísérleteknél, hogy lassítsd a jelszótippelést.
• Engedd a hosszú jelszavakat és a jelszókezelőket; hagyd ki a furcsa karakterkeverékre kényszerítő szabályokat.

Mágikus linkek és egyszer használatos kódok

A mágikus link a felhasználónak e-mailben küldött bejelentkezési link. Rákattintva bejelentkezik. Az egyszer használatos kód ugyanaz az elv, csak beírni kell kattintás helyett.

• A linkek és a kódok gyorsan lejárnak, és csak egyszer működnek.
• A linknek azon az eszközön kell bejelentkeztetnie a felhasználót, ahol rákattintott, a tokent pedig nem szabad naplókban vagy analitikai eszközökben tárolni.
• Megbízható e-mail-küldésre van szükséged – lásd: hogyan küldj e-maileket az appodból. Teszteld Gmaillel és Outlookkal, és nézd meg a spam-mappákat.

Bejelentkezés Google-lal (és más OAuth-szolgáltatók)

A „Bejelentkezés Google-lal” OAuth-t és OpenID Connectet használ: a Google igazolja, ki a felhasználó, és megmondja az appodnak az e-mailjét és a nevét. A beállítás 2026 szeptemberétől a Google Cloud Console Google Auth Platform részében történik:

1. Hozz létre vagy válassz egy projektet, és töltsd ki a Branding oldalt – ezt látják a felhasználók a beleegyezési képernyőn (az app neve, támogatási e-mail, logó).
2. A Clients oldalon hozz létre „Web application” típusú klienst.
3. Add meg az engedélyezett JavaScript-eredeteket és a átirányítási URI-kat – azokat a pontos címeket, ahol az appod fut, és ahová a Google a bejelentkezés után visszaküldi a felhasználót.
4. Tárold a kliensazonosítót és a kliens titkát az app titkai között.

A Google OAuth-dokumentációja szerint gyakran előforduló hibák:

• redirect_uri_mismatch: az átirányítási címnek pontosan egyeznie kell, beleértve a http és https különbséget, a nagybetűket és a záró perjelet. Adj hozzá egyet az előnézeti címedhez és egyet az éles domainedhez.
• HTTPS szükséges: az átirányítási URI-knak HTTPS-t kell használniuk, kivéve a localhost-ot fejlesztés közben.
• A state paramétert a visszatéréskor ellenőrizni kell a keresztoldali kérésészlelés (CSRF) elleni védelem érdekében. A jó könyvtárak ezt megteszik helyetted.

Ha csak alapvető bejelentkezési adatokat kérsz (név, e-mail, profil), a Google szerint az alkalmazás-ellenőrzés nem kötelező. A felhasználók Gmailjéhez, Drive-jához vagy Naptárához való hozzáférés kérése más, és ellenőrzést igényel.

Építsd meg, vagy használj szolgáltatót?

Az első kettő mindegyike ésszerű. A hosztolt szolgáltatók többet intéznek helyetted, de egy újabb függőséget jelentenek, és néha aktív felhasználónként fizetni kell értük; az aktuális árakat a honlapjukon ellenőrizd. A könyvtárak mindent az adatbázisodban tartanak, de több beállítás marad rád. Bármelyiket választod, kérd az AI-t, hogy azt használja, ne írjon kézzel jelszó- vagy munkamenet-logikát.

Szerepkörök és jogosultságok

A bejelentkezés azt mondja meg, ki valaki. A jogosultságok döntik el, mit tehet. Kezdetben tartsd egyszerűen:

A szerepkörnevekné fontosabb szabályok:

• Ellenőrizd a szerveren, minden alkalommal. Az oldalon elrejtett gomb nem akadályozza meg, hogy valaki közvetlenül hívja az API-t.
• Tulajdonos szerint szűrj. Egy tag, aki a „123-as foglalás” lekérését kéri, csak akkor kapja meg, ha az az övé.
• A felhasználók nem léphetnek elő maguk. Profilfrissítésnél hagyd figyelmen kívül a böngészőből érkező szerepkör-mezőket.
• Alapértelmezés: nincs hozzáférés. Az új útvonalaknak bejelentkezést kell kérniük, hacsak nem döntesz másként.

Teszteld két fiókkal: jelentkezz be az egyikkel, jegyezd meg egy rekord azonosítóját, majd jelentkezz be a másikkal, és próbáld megnyitni. A teljes tesztet a biztonsági ellenőrzőlistánk tartalmazza.

Munkamenet-biztonság

Bejelentkezés után az app munkamenettel jegyzi meg a felhasználót – általában sütivel. Az OWASP munkamenet-kezelési útmutatója a következőket javasolja:

• A munkamenet-sütik Secure (csak HTTPS), HttpOnly (oldalszkriptek nem olvashatják) és SameSite beállítással
• Új munkamenet-azonosító bejelentkezéskor, és újra, amikor a jogosultságok változnak
• Tétlenségi időtúllépés és abszolút maximális élettartam, a szerveren érvényesítve
• Kijelentkezés, amely a szerveren is megszünteti a munkamenetet, nem csak a sütit törli
• A munkamenetek érvénytelenednek, amikor a felhasználó megváltoztatja a jelszavát

A bejelentkezési tokenek böngészőbeli localStorage-ban tárolása a bemutatókban gyakori, de bármelyik, az oldalon futó szkript számára hozzáférhetővé teszi őket; webappoknál a biztonságos sütik általában a jobb alapértelmezés.

Prompt, amely a lényeget lefedi

Adj hozzá felhasználói fiókokat ehhez az apphoz. A felhasználók regisztrálhatnak és bejelentkezhetnek e-mail címmel és jelszóval, vagy Google-lal. Használj [könyvtár vagy szolgáltató] nevű megoldást, ne egyedi hitelesítő kódot. A jelszavakat hash-eld Argon2id vagy bcrypt segítségével. Adj e-mailes jelszó-visszaállítást egyszer használható linkkel, amely egy óra múlva lejár. A munkameneteket biztonságos, HttpOnly sütikben tartsd. Védd a /dashboard útvonalat és minden /api útvonalat úgy, hogy csak bejelentkezett felhasználók használhassák őket, és gondoskodj róla, hogy a felhasználók csak a saját projektjeiket lássák. Adj hozzá egy „admin” szerepkört, amely minden felhasználót láthat; az /admin oldalt csak az adminok érhetik el, a szerveren ellenőrizve.

Azután teszteld: regisztrálj, jelentkezz ki, jelentkezz be, állítsd vissza a jelszót, próbálj egy privát URL-t kijelentkezve megnyitni, és próbáld meg egy másik felhasználó rekordját.

Gyakori hibák az AI-val épített bejelentkezésben

• Védelem csak az oldalon. Az oldal átirányítja a kijelentkezett felhasználókat, de az API bárkinek visszaadja az adatokat.
• Titkok a böngészőben. Az OAuth-kliens titkai és a hitelesítő szolgáltató admin-kulcsai a szerverre valók.
• Előnézeti és éles URL-ek összekeverése. A Google átirányítási URI-ja vagy a visszaállító e-mail linkje az előnézetre mutat, így a bejelentkezés publikálás után elromlik.
• Nincs e-mail-megerősítés. Bárki regisztrálhat anyone@company.com címmel. Ellenőrizd az e-mail-címet, mielőtt az adott címhez kötött dolgokat engedélyeznél.
• Csak a sikeres út tesztelése. Próbálj rossz jelszavakat, lejárt linkeket és egy második fiókot.

Bejelentkezés hozzáadása a Mythexben

A Mythexen a saját appod felhasználóinak bejelentkezése az, amit az appodhoz adsz – ez független a saját Mythex-fiókodtól. A Mythex nem kínál beépített hitelesítési terméket, ezért te hozol egy hitelesítési könyvtárat vagy szolgáltatót és annak kulcsait:

1. Válassz megközelítést – például e-mail és jelszó a saját adatbázisodban tárolva, vagy egy hosztolt szolgáltató SDK-ja.
2. Ha a felhasználókat saját magad tárolod, az appnak adatbázis kell; kérd a chatben, vagy használd a /database parancsot.
3. A szolgáltató kulcsait tedd a projekt titkai közé (/secrets vagy a projektbeállítások).
4. Használj a fentihez hasonló promptot, majd teszteld az Előnézetben. Google-os bejelentkezésnél add hozzá az átirányítási URI-kat az előnézeti és a publikált címedhez is.

Lásd: Bejelentkezés hozzáadása az appodhoz a dokumentációban. Ha fizetős terméket építesz, a hogyan építs SaaS MVP-t útmutató a fiókokat és a számlázást együtt tárgyalja.

Kérdések