Што е автентикација? Најавување, сесии и OAuth објаснети

Автентикацијата е начинот на кој апликацијата потврдува кој е корисникот — обично со проверка на нешто што тој го знае (лозинка), нешто што го има (код испратен на телефонот или е-поштата) или идентитет од друга доверлива услуга (како „Најави се со Google“). Откако корисникот ќе биде автентициран, апликацијата го памети со сесија или токен, за да не мора да се најавува на секоја страница. Одлучувањето што тој познат корисник смее да прави е посебен чекор што се вика авторизација.

Зошто е важно кога градите со AI

Додавањето најава е едно од најчестите барања што луѓето им ги даваат на AI алатките за градење, и едно од најлесните за суптилно погрешно изведување. Страницата за најава е едноставна за генерирање. Тешкиот дел е сè околу неа:

• Дали лозинките се чуваат безбедно?
• Дали секоја приватна страница и секоја API крајна точка навистина проверува кој прашува?
• Може ли најавен клиент да ги види податоците на друг клиент ако промени број во URL-то?
• Што се случува кога некој ќе ја заборави лозинката?

Апликацијата може да изгледа сосема безбедна, а сепак да не ги исполнува сите овие точки. Разбирањето на движечките делови ви помага да ги поставите вистинските прашања и да тестирате вистинските работи.

Секојдневна аналогија

Замислете пријавување во хотел.

На рецепцијата ја покажувате личната карта. Тоа е автентикација: докажување кој сте. Рецепционерот потоа ви дава картичка за врата. Таа картичка е вашата сесија: за целиот престој не ја покажувате повторно личната карта; само ја допирате картичката.

Картичката ги отвора вашата соба, теретаната и лифтот до вашиот кат — но не и собите на другите гости или канцеларијата на вработените. Тоа е авторизација: до што има пристап вашиот идентитет. Ако ја изгубите картичката, хотелот може да ја деактивира на рецепција (повлекување на сесија). Кога ќе се одјавите, таа престанува да работи (одјава или истекување).

„Најави се со Google“ е како хотел што прима писмо од доверлив партнер со порака „ова е тој“, наместо сам да ја проверува вашата личност.

Главни методи за најава

Како треба да се чуваат лозинките

Безбедната апликација никогаш не ја чува вистинската лозинка. Наместо тоа, чува хеш: излезот од еднонасочна функција што лозинката ја претвора во фиксна низа. Кога се најавувате, апликацијата го хешира она што го внесовте и го споредува резултатот со зачуваниот хеш.

Две детали го прават ова безбедно:

• Сол — случајна вредност додадена на секоја лозинка пред хеширање, така што два луѓе со иста лозинка добиваат различни хешови, а претходно пресметаните табели за барање не помагаат.
• Бавен алгоритам направен за лозинки — како Argon2, bcrypt или scrypt. Општите хешови како MD5 или SHA-256 сами по себе се премногу брзи; напаѓачите можат да пробаат милијарди погодувања.

Хеширањето не е исто што и шифрирањето. Шифрираните податоци можат да се дешифрираат со клуч; хешот на лозинка е дизајниран воопшто да не се враќа назад.

Сесии наспрема токени

По најавата, апликацијата мора да ве препознава при секое барање. Постојат два вообичаени пристапа.

За колачињата, три поставки се важни: HttpOnly (JavaScript на страницата не може да го чита колачето), Secure (се испраќа само преку HTTPS) и SameSite (ограничува испраќање на барања од други сајтови). Чувањето токени во localStorage на прелистувачот е вообичаено, но ги изложува на секоја скрипта што работи на страницата.

OAuth и „Најави се со Google“

OAuth 2.0 е стандард за делегирана авторизација: овозможува апликацијата да добие ограничен пристап до вашата сметка на друга услуга — на пример, да ја чита вашата Google календар — без никогаш да ја види вашата Google лозинка. Ве праќаат кај Google, одобрувате конкретни дозволи (наречени опсези (scopes)), а Google ѝ дава на апликацијата токен само за тие дозволи.

OAuth сам по себе е создаден за да дава пристап, а не за да каже кој сте. OpenID Connect (OIDC) е слој над OAuth 2.0 што додава идентитет, а тоа го користи „Најави се со Google“ или „Најави се со Apple“. За поставување, ја регистрирате апликацијата кај провајдерот и добивате client ID и client secret; тајната останува на вашиот сервер.

Работен пример: најава за клиентски портал

Замислете портал каде клиентите на една дизајнерска агенција ги гледаат своите проекти и фактури.

• Автентикација: клиентите се најавуваат со е-пошта и магичен линк, па нема лозинки за управување. Вработените во агенцијата се најавуваат со Google Workspace сметки.
• Улоги: секој корисник има улога — client или staff.
• Правила за авторизација:

• Каде се спроведува: на серверот, за секое барање. Серверот го бара најавениот корисник, па враќа само проекти каде project.company_id се совпаѓа со компанијата на корисникот. Скривањето на копчето „Означи платено“ не е доволно — самата крајна точка мора да одбие.

Објаснети поими

Чести грешки и заблуди

• Проверка на дозволи само во страницата. Ако прелистувачот го крие копчето, но API-то не проверува, секој може директно да го повика API-то.
• Верување на ID-та од URL-то. /invoices/1042 мора да провери дали фактура 1042 припаѓа на најавениот корисник.
• Самостојно создавање криптографија. Користете познати библиотеки или провајдери; не дозволувајте AI да измисли своја шема за хеширање.
• Слабо ресетирање на лозинка. Линковите за ресетирање треба да се еднократни, да истекуваат брзо и да не откриваат дали е-поштата има сметка.
• Мешање на вашата најава со најавата на алатката со која градите. Корисниците на вашата апликација се одвоени од вашата сметка на алатката со која ја градите.
• Нема ограничување на обидите за најава. Без него, напаѓачите можат бескрајно да пробуваат лозинки.

Што да побарате од вашата AI алатка

• „Додај регистрација и најава со [познат библиотека или провајдер]. Не пишувај сопствено хеширање на лозинки.“
• „Чувај ги лозинките хеширани со bcrypt или Argon2.“
• „Користи HttpOnly и Secure колачиња за сесијата.“
• „Додај улоги: admin и member. Наведи ја секоја крајна точка и кои улоги смеат да ја повикаат.“
• „Спроведи на серверот дека корисниците смеат да читаат и уредуваат само свои записи. Потоа покажи ми како си проверил.“
• „Додај ресетирање на лозинка со еднократни линкови што истекуваат за еден час.“
• „Ограничи ги обидите за најава.“

Потоа тестирајте сами: создајте две сметки и обидете се да пристапите до податоците на едната додека сте најавени со другата. Нашиот водич за додавање најава и безбедносната листа одат подалеку.

Автентикација во Mythex

Mythex не нуди вградена автентикациска услуга за корисниците на вашата апликација; вие го избирате пристапот — е-пошта и лозинка зачувани во базата на податоци на вашиот проект, или SDK на хостиран провајдер — и го замолувате агентот да го додаде. Клучевите на провајдерите одат во тајни на проектот, не во чат. Ова е одвоено од тоа како се најавувате во самиот Mythex. Рецептот во документацијата за додавање најава во вашата апликација има почетна порака што можете да ја приспособите, а што е API објаснува каде се наоѓаат тие проверки на серверот.

Прашања