Mi a hitelesítés? Bejelentkezés, munkamenetek és OAuth magyarázattal

A hitelesítés az, ahogy egy app megerősíti, ki a felhasználó – általában valamit ellenőriz, amit ő tud (jelszót), vagy amije van (telefonra vagy e-mailbe küldött kódot), vagy egy másik megbízható szolgáltatótól származó identitást (például a „Bejelentkezés Google-lel” funkciót). Miután a felhasználó hitelesítve lett, az app munkamenettel vagy tokennel emlékszik rá, hogy ne kelljen minden oldalon újra bejelentkeznie. Az, hogy a megismert felhasználó mit tehet, külön lépés, amelyet jogosultságkezelésnek (authorization) hívnak.

Miért fontos, ha AI-val építesz

A bejelentkezés hozzáadása az egyik leggyakoribb kérés egy AI-építőnél, és az egyik legkönnyebben finoman elrontható dolog. Egy bejelentkező oldalt könnyű legenerálni. A nehéz rész mindaz, ami körülötte van:

• Biztonságosan vannak-e tárolva a jelszavak?
• Minden privát oldal és minden API-végpont ellenőrzi-e valóban, ki kéri?
• Láthat-e egy bejelentkezett vásárló más vásárló adatait azzal, hogy átírja a számot az URL-ben?
• Mi történik, ha valaki elfelejti a jelszavát?

Egy app kívülről tökéletesen biztonságosnak tűnhet, miközben mindegyik ponton elbukik. A működő részek megértése segít abban, hogy a megfelelő kérdéseket tedd fel és a megfelelő dolgokat teszteld.

Mindennapi hasonlat

Gondolj arra, amikor szállodába jelentkezel be.

A recepción felmutatod az igazolványodat. Ez a hitelesítés: bizonyítod, ki vagy. A recepciós ezután kulcskártyát ad. Ez a kártya a munkameneted: a tartózkodásod hátralévő részében nem kell újra igazolványt mutatnod, csak a kártyát érintened.

A kártya kinyitja a szobádat, az edzőtermet és a liftet a szintedre – de nem a többi vendég szobáját vagy az irodát. Ez a jogosultságkezelés: hogy az azonosságod mihez férhet hozzá. Ha elveszíted a kártyát, a szálloda a pultnál deaktiválhatja (ez a munkamenet visszavonása). Kijelentkezéskor vagy lejáratkor megszűnik a működése.

A „Bejelentkezés Google-lel” olyan, mintha a szálloda egy megbízható partnertől kapott levélre hagyatkozna, amely szerint „ez az illető”, ahelyett, hogy maga ellenőrizné az igazolványodat.

A fő bejelentkezési módszerek

Hogyan kell tárolni a jelszavakat

Egy biztonságos app soha nem tárolja a tényleges jelszavadat. Helyette egy hash-t tárol: egy visszafordíthatatlan függvény kimenetét, amely a jelszót fix hosszúságú sztringgé alakítja. Bejelentkezéskor az app hash-eli, amit beírtál, és összehasonlítja az eredményt a tárolt hash-sel.

Két részlet teszi ezt biztonságossá:

• Só (salt) – egy véletlenszerű érték, amelyet minden jelszóhoz hozzáadnak a hash-elés előtt, így két ember azonos jelszava is különböző hash-t ad, és az előre kiszámolt keresőtáblák haszontalanok.
• Lassú, jelszavakhoz készült algoritmus – például Argon2, bcrypt vagy scrypt. Az általános célú hash-ek, mint az MD5 vagy a SHA-256, önmagukban túl gyorsak; a támadók milliárdnyi tippet próbálhatnak ki.

A hash-elés nem ugyanaz, mint a titkosítás. A titkosított adat kulccsal visszafejthető; a jelszó-hash úgy készült, hogy egyáltalán ne legyen visszafordítható.

Munkamenetek vs tokenek

Bejelentkezés után az appnak minden kérésnél fel kell ismernie téged. Két gyakori megközelítés van.

Sütiknél három beállítás számít: HttpOnly (az oldalon futó JavaScript nem olvashatja a sütit), Secure (csak HTTPS-en küldődik) és SameSite (korlátozza a küldést más oldalakról érkező kérésekben). A tokenek böngészős localStorage-ban való tárolása gyakori, de így bármely, az oldalon futó szkript hozzáfér.

OAuth és a „Bejelentkezés Google-lel”

Az OAuth 2.0 delegált jogosultságkezelés szabványa: lehetővé teszi, hogy egy app korlátozott hozzáférést kapjon a fiókodhoz egy másik szolgáltatásnál – mondjuk a Google-naptáradat olvasásához –, anélkül hogy valaha látná a Google-jelszavadat. A Google-hoz irányítanak, te jóváhagyod a konkrét engedélyeket (ezeket scope-oknak hívják), a Google pedig csak ezekre az engedélyekre szóló tokent ad az appnak.

Az OAuth önmagában arra készült, hogy hozzáférést adjon, nem arra, hogy megmondja, ki vagy. Az OpenID Connect (OIDC) az OAuth 2.0 fölé épülő réteg, amely identitást ad hozzá – ezt használja a „Bejelentkezés Google-lel” vagy az „Bejelentkezés Apple-lel”. A beállításhoz regisztrálod az appodat a szolgáltatónál, és kapsz egy kliensazonosítót (client ID) és egy kliens titkot (client secret); a titok a szerveren marad.

Példa: bejelentkezés egy ügyfélportálhoz

Tegyük fel, hogy egy tervezőirodának portált építesz, ahol az ügyfelek látják a projektjeiket és számláikat.

• Hitelesítés: az ügyfelek e-mailben és mágikus linkkel jelentkeznek be, így nincs kezelendő jelszó. Az iroda munkatársai Google Workspace-fiókokkal jelentkeznek be.
• Szerepkörök: minden felhasználónak van egy szerepköre – client vagy staff.
• Jogosultsági szabályok:

• Hol érvényesül: a szerveren, minden kérésnél. A szerver megkeresi a bejelentkezett felhasználót, majd csak azokat a projekteket adja vissza, ahol a project.company_id egyezik a felhasználó cégével. Nem elég elrejteni a „Fizetettnek jelöl” gombot – a végpontnak magának kell megtagadnia.

Gyakori fogalmak magyarázata

Gyakori hibák és tévhitek

• Jogosultság ellenőrzése csak az oldalon. Ha a böngésző elrejt egy gombot, de az API nem ellenőriz, bárki közvetlenül hívhatja az API-t.
• Az URL-ben szereplő azonosítókban bízni. A /invoices/1042 esetén ellenőrizni kell, hogy az 1042-es számla a bejelentkezett felhasználóé.
• Saját kriptográfia írása. Jól ismert könyvtárakat vagy szolgáltatókat használj; ne engedd, hogy az AI kitaláljon egy hash-sémát.
• Gyenge jelszó-visszaállítás. A visszaállító linkek legyenek egyszer használhatók, gyorsan járjanak le, és ne áruljanak el, van-e fiók az e-mail-címhez.
• Összekeverni a saját bejelentkezésed az építőeszközével. Az app felhasználói különállnak a fiókodtól az eszközön, amellyel építed.
• Nincs korlátozás a bejelentkezési próbálkozásokra. Enélkül a támadók végtelenül próbálkozhatnak jelszavakkal.

Mit kérj az AI-építőtől

• „Adj regisztrációt és bejelentkezést [egy jól ismert könyvtárral vagy szolgáltatóval]. Ne írj egyedi jelszó-hash-elést.”
• „A jelszavakat bcrypt vagy Argon2 segítségével hash-eld és tárold.”
• „A munkamenethez HttpOnly, Secure sütiket használj.”
• „Adj szerepköröket: admin és member. Sorold fel minden végpontot, és hogy melyik szerepkör hívhatja.”
• „A szerveren érvényesítsd, hogy a felhasználók csak a saját rekordjaikat láthassák és szerkeszthessék. Utána mutasd meg, hogyan ellenőrizted.”
• „Adj jelszó-visszaállítást egyszer használható linkekkel, amelyek egy óra múlva lejárnak.”
• „Korlátozd a bejelentkezési próbálkozások számát.”

Utána teszteld magad: hozz létre két fiókot, és próbáld meg az egyik bejelentkezve elérni a másik adatait. A bejelentkezés hozzáadásáról szóló útmutató és a biztonsági ellenőrzőlista tovább visz.

Hitelesítés a Mythexben

A Mythex nem ad beépített hitelesítési terméket az appod felhasználóinak; te választasz egy megközelítést – e-mail és jelszó az appod projektadatbázisában tárolva (adatbázis), vagy egy hosztolt szolgáltató SDK-ja –, és megkéred az ügynököt, hogy adja hozzá. A szolgáltatói kulcsok projekt-titkokba kerülnek, nem a chatbe. Ez különbözik attól, ahogy magába a Mythexbe jelentkezel be. A dokumentációs recept a bejelentkezés hozzáadásáról az appodhoz egy átalakítható kezdő promptot tartalmaz, a mi az API pedig elmagyarázza, hol élnek ezek a szerveroldali ellenőrzések.

Kérdések