Co je autentizace? Přihlášení, relace a OAuth srozumitelně

Autentizace je způsob, jakým aplikace ověřuje, kdo uživatel je — obvykle kontrolou něčeho, co zná (heslo), něčeho, co má (kód poslaný na telefon nebo e-mail), nebo identity z jiné důvěryhodné služby (například „Přihlásit přes Google"). Jakmile je uživatel ověřen, aplikace si ho zapamatuje pomocí relace nebo tokenu, takže se nemusí přihlašovat na každé stránce. Rozhodnutí, co tento známý uživatel smí dělat, je samostatný krok zvaný autorizace.

Proč na tom záleží, když stavíte s AI

Přidání přihlášení patří k nejčastějším požadavkům, které lidé AI nástroji zadávají, a zároveň se v něm snadno nenápadně spletete. Přihlašovací stránku lze snadno vygenerovat. Těžká část je všechno kolem ní:

• Jsou hesla uložena bezpečně?
• Kontroluje každá soukromá stránka a každý koncový bod API, kdo se ptá?
• Může přihlášený zákazník vidět data jiného zákazníka, když změní číslo v URL?
• Co se stane, když někdo zapomene heslo?

Aplikace může vypadat naprosto bezpečně, a přitom selhávat ve všech těchto bodech. Pochopení jednotlivých částí vám pomůže klást správné otázky a testovat správné věci.

Každodenní přirovnání

Představte si check-in v hotelu.

Na recepci ukážete doklad. To je autentizace: prokázání, kdo jste. Recepční vám dá kartu do pokoje. Tahle karta je vaše relace: po zbytek pobytu se neprokazujete znovu, jen přiložíte kartu.

Karta otevírá váš pokoj, posilovnu a výtah do vašeho patra — ale ne pokoje jiných hostů ani kancelář personálu. To je autorizace: k čemu má vaše identita přístup. Když kartu ztratíte, hotel ji může na recepci deaktivovat (zrušení relace). Při odhlášení přestane fungovat (odhlášení nebo vypršení platnosti).

„Přihlášení přes Google" je jako když hotel přijme dopis od důvěryhodného partnera, že „tohle je ten a ten host", místo aby kontroloval váš doklad sám.

Hlavní způsoby přihlášení

Jak se mají hesla ukládat

Bezpečná aplikace nikdy neukládá skutečné heslo. Místo toho ukládá hash: výstup jednosměrné funkce, která heslo převede na pevný řetězec. Když se přihlašujete, aplikace zahashuje to, co jste zadali, a výsledek porovná s uloženým hashem.

Bezpečnost zajišťují dva detaily:

• Sůl (salt) — náhodná hodnota přidaná ke každému heslu před hashováním, takže dva lidé se stejným heslem mají různé hashe a předpočítané tabulky jsou k ničemu.
• Pomalý algoritmus určený pro hesla — například Argon2, bcrypt nebo scrypt. Univerzální hashe jako MD5 nebo SHA-256 jsou samy o sobě příliš rychlé; útočník může zkusit miliardy odhadů.

Hashování není totéž co šifrování. Zašifrovaná data lze dešifrovat klíčem; hash hesla je navržen tak, aby nešel vrátit zpět vůbec.

Relace vs tokeny

Po přihlášení musí aplikace při každém požadavku poznat, kdo jste. Existují dva běžné přístupy.

U cookie záleží na třech nastaveních: HttpOnly (JavaScript na stránce cookie nemůže číst), Secure (odesílá se jen přes HTTPS) a SameSite (omezuje odeslání při požadavcích z jiných webů). Ukládání tokenů do localStorage prohlížeče je časté, ale vystavuje je každému skriptu, který na stránce běží.

OAuth a „Přihlásit přes Google"

OAuth 2.0 je standard pro delegovanou autorizaci: umožňuje aplikaci získat omezený přístup k vašemu účtu v jiné službě — řekněme ke čtení vašeho kalendáře Google — aniž by kdy viděla vaše heslo ke Googlu. Jste přesměrováni na Google, schválíte konkrétní oprávnění (nazývaná scopes) a Google aplikaci vydá token jen pro tato oprávnění.

OAuth sám o sobě byl navržen k udělování přístupu, ne k tomu, aby říkal, kdo jste. OpenID Connect (OIDC) je vrstva nad OAuth 2.0, která přidává identitu — právě to používá „Přihlásit přes Google" nebo „Přihlásit přes Apple". Pro nastavení zaregistrujete aplikaci u poskytovatele a dostanete client ID a client secret; tajný klíč zůstává na vašem serveru.

Praktický příklad: přihlášení do klientského portálu

Představme si, že stavíte portál, kde klienti designérské agentury vidí své projekty a faktury.

• Autentizace: klienti se přihlašují e-mailem a jednorázovým odkazem, takže nemusí spravovat hesla. Zaměstnanci agentury se přihlašují účty Google Workspace.
• Role: každý uživatel má roli — client nebo staff.
• Pravidla autorizace:

• Kde se vynucuje: na serveru, u každého požadavku. Server najde přihlášeného uživatele a vrátí jen projekty, kde se project.company_id shoduje s firmou uživatele. Schovat tlačítko „Označit jako zaplaceno" nestačí — koncový bod sám musí odmítnout.

Běžné pojmy vysvětlené

Časté chyby a omyly

• Kontrola oprávnění jen na stránce. Pokud prohlížeč tlačítko schová, ale API nekontroluje, může kdokoli volat API přímo.
• Důvěra ID v URL. /invoices/1042 musí ověřit, že faktura 1042 patří přihlášenému uživateli.
• Vlastní kryptografie. Používejte známé knihovny nebo poskytovatele; nenechte AI vymýšlet vlastní schéma hashování.
• Slabé obnovení hesla. Odkazy pro obnovu mají být jednorázové, rychle expirovat a nesmí prozrazovat, zda e-mail má účet.
• Záměna vašeho přihlášení s přihlášením do nástroje, ve kterém stavíte. Uživatelé vaší aplikace jsou oddělení od vašeho účtu u nástroje, ve kterém aplikaci stavíte.
• Žádné omezení pokusů o přihlášení. Bez něj mohou útočníci zkoušet hesla donekonečna.

Co požádat od svého AI nástroje

• „Přidej registraci a přihlášení pomocí [známé knihovny nebo poskytovatele]. Nepiš vlastní hashování hesel."
• „Ukládej hesla hashovaná pomocí bcrypt nebo Argon2."
• „Pro relaci použij cookie s HttpOnly a Secure."
• „Přidej role: admin a member. Vypiš každý koncový bod a které role ho smějí volat."
• „Vynuť na serveru, aby uživatelé mohli číst a upravovat jen své vlastní záznamy. Pak mi ukaž, jak jsi to ověřil."
• „Přidej obnovení hesla s jednorázovými odkazy, které vyprší za hodinu."
• „Omez počet pokusů o přihlášení."

Pak to otestujte sami: vytvořte dva účty a zkuste se z jednoho přihlášeného dostat k datům druhého. Průvodce přidáním přihlášení a kontrolní seznam zabezpečení jdou dál.

Autentizace v Mythexu

Mythex neposkytuje vestavěný autentizační produkt pro uživatele vaší aplikace; zvolíte přístup — e-mail a heslo uložené v databázi vašeho projektu, nebo SDK hostované služby — a požádáte agenta, aby ho přidal. Klíče poskytovatele patří do tajných hodnot projektu, ne do chatu. Toto je oddělené od toho, jak se přihlašujete do samotného Mythexu. Recept v dokumentaci o přidání přihlášení do aplikace obsahuje výchozí zadání, které můžete upravit, a co je API vysvětluje, kde tyto kontroly na serveru žijí.

Otázky