Какво е удостоверяване? Вход, сесии и OAuth, обяснено

Удостоверяването е начинът, по който приложението потвърждава кой е потребителят – обикновено като проверява нещо, което той знае (парола), нещо, което притежава (код, изпратен на телефона или имейла му), или идентичност от друга надеждна услуга (например „Вход с Google“). След като потребителят е удостоверен, приложението го помни със сесия или токен, така че да не се налага да влиза при всяка страница. Решението какво този известен потребител има право да прави е отделна стъпка, наречена оторизация.

Защо е важно, когато създаваш с ИИ

Добавянето на вход е една от най-честите заявки към ИИ инструмент за създаване на приложения и една от най-лесните за объркване по фина начин. Страницата за вход е проста за генериране. Трудната част е всичко около нея:

• Съхраняват ли се паролите безопасно?
• Проверява ли всяка частна страница и всяка API точка действително кой пита?
• Може ли клиент, който е влязъл, да види данните на друг клиент, като промени число в адреса?
• Какво се случва, когато някой забрави паролата си?

Приложението може да изглежда напълно сигурно и същевременно да се провали по всяко от тези неща. Разбирането на подвижните части ви помага да задавате правилните въпроси и да тествате правилните неща.

Ежедневна аналогия

Представете си настаняване в хотел.

На рецепцията показвате документ за самоличност. Това е удостоверяване: доказвате кой сте. Служителят след това ви дава карта за стая. Тази карта е вашата сесия: през останалото време от престоя не показвате документа си отново – просто докосвате картата.

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

„Вход с 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-то директно.
• Доверие на идентификатори от адреса. /invoices/1042 трябва да проверява дали фактура 1042 принадлежи на влезлия потребител.
• Самостоятелно измисляне на криптография. Използвайте добре познати библиотеки или доставчици; не оставяйте ИИ да измисля схема за хеширане.
• Слабо възстановяване на парола. Линковете за възстановяване трябва да се използват еднократно, да изтичат бързо и да не показват дали даден имейл има акаунт.
• Смесване на вашия вход с този на инструмента, с който строите. Потребителите на вашето приложение са отделни от акаунта ви в инструмента, с който го създавате.
• Без ограничение на опитите за вход. Без него нападателите могат безкрайно да пробват пароли.

Какво да поискате от вашия ИИ инструмент

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

После тествайте сами: създайте два акаунта и опитайте да достъпите данните на единия, докато сте влезли като другия. Нашето ръководство за добавяне на вход и контролен списък за сигурност вървят по-далеч.

Удостоверяване в Mythex

Mythex не предоставя вграден продукт за удостоверяване на потребителите на вашето приложение; вие избирате подход – имейл и парола, съхранени в базата данни на проекта, или SDK на хостван доставчик – и помолите агента да го добави. Ключовете на доставчика се поставят в тайните на проекта, не в чата. Това е отделно от това как влизате в самия Mythex. Рецептата в документацията за добавяне на вход към приложението съдържа стартов промпт, който можете да адаптирате, а какво е API обяснява къде се намират тези проверки на сървъра.

Въпроси