Čo je autentifikácia? Prihlasovanie, relácie a OAuth vysvetlené

Autentifikácia je spôsob, akým aplikácia potvrdí, kto je používateľ – zvyčajne kontrolou niečoho, čo používateľ pozná (heslo), niečoho, čo má (kód poslaný na telefón alebo e-mail), alebo identity od inej dôveryhodnej služby (napríklad „Prihlásiť sa cez Google“). Keď je používateľ overený, aplikácia si ho zapamätá pomocou relácie alebo tokenu, aby sa nemusel prihlasovať na každej stránke. Rozhodnutie, čo môže tento známy používateľ robiť, je samostatný krok nazývaný autorizácia.

Prečo na tom záleží, keď stavate s AI

Pridanie prihlásenia patrí k najbežnejším požiadavkám na nástroje na tvorbu aplikácií a zároveň sa dá ľahko pokaziť nenápadne. Prihlasovacia stránka sa dá vygenerovať jednoducho. Ťažké je všetko okolo nej:

• Sú heslá uložené bezpečne?
• Kontroluje každá súkromná stránka a každý koncový bod API, kto sa pýta?
• Dokáže prihlásený zákazník zobraziť dáta iného zákazníka zmenou čísla v URL?
• Čo sa stane, keď si niekto zabudne heslo?

Aplikácia môže vyzerať úplne bezpečne a pritom zlyhávať v každom z týchto bodov. Keď rozumiete pohyblivým častiam, viete klásť správne otázky a testovať správne veci.

Každodenná analógia

Predstavte si prihlásenie do hotela.

Na recepcii ukážete doklad totožnosti. To je autentifikácia: dokázanie, kto ste. Recepčná vám potom dá kartu do izby. Táto karta je vaša relácia: počas celého pobytu sa už nemusíte preukazovať, stačí priložiť kartu.

Karta otvorí vašu izbu, fitnes a výťah na vaše poschodie – ale nie izby iných hostí ani kancelárie personálu. To je autorizácia: k čomu má vaša identita prístup. Ak kartu stratíte, hotel ju môže na recepcii deaktivovať (odvolanie relácie). Pri odchode prestane fungovať (odhlásenie alebo vypršanie).

„Prihlásiť sa cez Google“ je ako keď hotel prijme list od dôveryhodného partnera, ktorý hovorí „toto je ten, kto je“, namiesto toho, aby vašu totožnosť kontroloval sám.

Hlavné spôsoby prihlásenia

Ako sa majú ukladať heslá

Bezpečná aplikácia nikdy neukladá vaše skutočné heslo. Namiesto toho ukladá hash: výstup jednosmernej funkcie, ktorá heslo premení na pevný reťazec. Keď sa prihlasujete, aplikácia zahashuje to, čo ste napísali, a porovná výsledok s uloženým hashom.

Dva detaily robia tento postup bezpečným:

• Soľ (salt) – náhodná hodnota pridaná ku každému heslu pred hashovaním, takže dvaja ľudia s rovnakým heslom majú rôzne hashe a predpočítané tabuľky sú bezcenné.
• Pomalý algoritmus určený na heslá – napríklad Argon2, bcrypt alebo scrypt. Všeobecné hashe ako MD5 alebo SHA-256 sú samy o sebe príliš rýchle; útočník môže skúsiť miliardy hádaní.

Hashovanie nie je to isté ako šifrovanie. Zašifrované dáta sa dajú dešifrovať kľúčom; hash hesla je navrhnutý tak, aby sa vôbec nedal obrátiť.

Relácie vs tokeny

Po prihlásení musí aplikácia pri každej požiadavke spoznať, kto ste. Existujú dva bežné prístupy.

Pri cookie sú dôležité tri nastavenia: HttpOnly (JavaScript na stránke nemôže cookie čítať), Secure (odosiela sa len cez HTTPS) a SameSite (obmedzuje odosielanie pri požiadavkách z iných stránok). Ukladanie tokenov do localStorage prehliadača je bežné, ale vystavuje ich každému skriptu bežiacemu na stránke.

OAuth a „Prihlásiť sa cez Google“

OAuth 2.0 je štandard pre delegovanú autorizáciu: umožňuje aplikácii získať obmedzený prístup k vášmu účtu v inej službe – napríklad čítať váš Google kalendár – bez toho, aby kedy videla vaše heslo do Google. Presmerujú vás na Google, schválite konkrétne oprávnenia (nazývané scopes) a Google aplikácii dá token iba na tieto oprávnenia.

Samotný OAuth bol navrhnutý na udelenie prístupu, nie na to, aby hovoril, kto ste. OpenID Connect (OIDC) je vrstva nad OAuth 2.0, ktorá pridáva identitu – presne to používa „Prihlásiť sa cez Google“ alebo „Prihlásiť sa cez Apple“. Na nastavenie zaregistrujete aplikáciu u poskytovateľa a dostanete client ID a client secret; tajomstvo zostáva na vašom serveri.

Praktický príklad: prihlásenie do klientskeho portálu

Predstavte si portál, v ktorom klienti dizajnérskej agentúry vidia svoje projekty a faktúry.

• Autentifikácia: klienti sa prihlasujú e-mailom a magic linkom, takže nemusia spravovať heslá. Zamestnanci agentúry sa prihlasujú cez účty Google Workspace.
• Roly: každý používateľ má rolu – client alebo staff.
• Pravidlá autorizácie:

• Kde sa to vynucuje: na serveri, pri každej požiadavke. Server nájde prihláseného používateľa a vráti len projekty, kde sa project.company_id zhoduje s firmou používateľa. Skryť tlačidlo „Označiť ako zaplatené“ nestačí – koncový bod sám musí odmietnuť.

Vysvetlenie bežných pojmov

Bežné chyby a omyly

• Kontrola oprávnení len v stránke. Ak prehliadač skryje tlačidlo, ale API nekontroluje, ktokoľvek môže zavolať API priamo.
• Dôverovanie ID z URL. /invoices/1042 musí overiť, že faktúra 1042 patrí prihlásenému používateľovi.
• Vlastná kryptografia. Používajte známe knižnice alebo poskytovateľov; nenechajte AI vymýšľať vlastnú schému hashovania.
• Slabá obnova hesla. Odkazy na obnovu majú byť jednorazové, rýchlo vypršať a nesmú prezradiť, či e-mail má účet.
• Zamieňanie vášho prihlásenia s prihlásením do nástroja, ktorým stavate. Používatelia vašej aplikácie sú oddelení od vášho účtu v nástroji, ktorým ju tvoríte.
• Žiadne obmedzenie pokusov o prihlásenie. Bez neho môžu útočníci skúšať heslá donekonečna.

Čo požiadať od nástroja na tvorbu aplikácií

• „Pridaj registráciu a prihlásenie pomocou [známej knižnice alebo poskytovateľa]. Nepíš vlastné hashovanie hesiel.“
• „Ukladaj heslá zahashované pomocou bcrypt alebo Argon2.“
• „Pre reláciu použi cookie s HttpOnly a Secure.“
• „Pridaj roly: admin a member. Vypíš každý koncový bod a ktoré roly ho smú volať.“
• „Na serveri vynúť, aby používatelia mohli čítať a upravovať len svoje vlastné záznamy. Potom mi ukáž, ako si to overil.“
• „Pridaj obnovu hesla s jednorazovými odkazmi, ktoré vypršia za hodinu.“
• „Obmedz počet pokusov o prihlásenie.“

Potom to otestujte sami: vytvorte dva účty a skúste sa dostať k dátam jedného, keď ste prihlásení ako druhý. Sprievodca pridaním prihlásenia a bezpečnostný kontrolný zoznam idú ďalej.

Autentifikácia v Mythex

Mythex neposkytuje vstavaný produkt na autentifikáciu používateľov vašej aplikácie; zvolíte prístup – e-mail a heslo uložené v databáze vášho projektu alebo SDK hostovanej služby – a požiadate agenta, aby ho pridal. Kľúče poskytovateľa idú do tajomstiev projektu, nie do chatu. Toto je oddelené od toho, ako sa prihlasujete do samotného Mythex. Recept v dokumentácii o pridaní prihlásenia do aplikácie obsahuje štartovací prompt, ktorý môžete upraviť, a čo je API vysvetľuje, kde tieto kontroly na serveri žijú.

Otázky