Що таке автентифікація? Входи, сесії та OAuth пояснено

Автентифікація — це спосіб, яким застосунок підтверджує, хто є користувачем. Зазвичай перевіряється щось, що людина знає (пароль), щось, що вона має (код, надісланий на телефон чи електронну пошту), або посвідчення від іншого довіреного сервісу (наприклад, «Увійти через Google»). Коли користувача автентифіковано, застосунок запам'ятовує його за допомогою сесії або токена, щоб йому не доводилося входити на кожній сторінці. Вирішення того, що саме цьому відомому користувачеві дозволено робити, — окремий крок, який називається авторизацією.

Чому це важливо, коли ви створюєте з ШІ

Додавання входу — один із найпоширеніших запитів до ШІ-конструкторів і один із найлегших для тонких помилок. Сторінку входу згенерувати просто. Складна частина — все навколо неї:

• Чи безпечно зберігаються паролі?
• Чи перевіряє кожна приватна сторінка і кожна кінцева точка API, хто запитує?
• Чи може клієнт, який увійшов, побачити дані іншого клієнта, змінивши число в URL?
• Що відбувається, коли хтось забуває пароль?

Застосунок може виглядати цілком безпечним і при цьому провалювати кожен із цих пунктів. Розуміння рухомих частин допоможе ставити правильні запитання і перевіряти правильні речі.

Повсякденна аналогія

Уявіть, що ви заселяєтеся в готель.

На стійці реєстрації ви показуєте документ. Це автентифікація: доведення, хто ви є. Адміністратор видає вам картку-ключ. Ця картка — ваша сесія: протягом проживання ви більше не показуєте документ, а лише прикладаєте картку.

Картка відкриває ваш номер, спортзал і ліфт на вашому поверсі, але не номери інших гостей і не службове приміщення. Це авторизація: до чого ваша особа має доступ. Якщо ви загубите картку, готель може деактивувати її на стійці (відкликання сесії). Коли ви виїжджаєте, вона перестає працювати (вихід із системи або закінчення строку).

«Увійти через Google» — це як коли готель приймає лист від довіреного партнера, в якому написано «це така-то особа», замість того щоб перевіряти ваш документ самостійно.

Основні способи входу

Як слід зберігати паролі

Безпечний застосунок ніколи не зберігає ваш справжній пароль. Натомість він зберігає хеш: результат односторонньої функції, яка перетворює пароль на фіксований рядок. Коли ви входите, застосунок хешує введене вами і порівнює результат із збереженим хешем.

Дві деталі роблять це безпечним:

• Сіль — випадкове значення, що додається до кожного пароля перед хешуванням, тож два люди з однаковим паролем матимуть різні хеші, а заздалегідь обчислені таблиці пошуку марні.
• Повільний алгоритм, створений для паролів — наприклад Argon2, bcrypt або scrypt. Універсальні хеші на кшталт MD5 чи SHA-256 самі по собі занадто швидкі; зловмисники можуть перебрати мільярди варіантів.

Хешування — це не шифрування. Зашифровані дані можна розшифрувати ключем; хеш пароля спроєктовано так, щоб його взагалі не можна було повернути назад.

Сесії проти токенів

Після входу застосунку потрібно впізнавати вас у кожному запиті. Є два поширені підходи.

Для cookie важливі три налаштування: HttpOnly (JavaScript на сторінці не може прочитати cookie), 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 напряму.
• Довіра до ідентифікаторів з URL. /invoices/1042 має перевіряти, що рахунок 1042 належить користувачеві, який увійшов.
• Створення власної криптографії. Використовуйте відомі бібліотеки чи провайдерів; не дозволяйте ШІ вигадувати власну схему хешування.
• Слабке скидання пароля. Посилання для скидання мають працювати лише один раз, швидко спливати і не показувати, чи є обліковий запис для цієї пошти.
• Плутанина між входом у ваш застосунок і входом у ваш конструктор. Користувачі вашого застосунку відокремлені від вашого облікового запису в інструменті, яким ви його створюєте.
• Немає обмеження спроб входу. Без нього зловмисники можуть безкінечно підбирати паролі.

Що просити у вашого ШІ-конструктора

• «Додай реєстрацію і вхід, використовуючи [відому бібліотеку або провайдера]. Не пиши власне хешування паролів».
• «Зберігай паролі з хешуванням bcrypt або Argon2».
• «Для сесії використовуй cookie з HttpOnly і Secure».
• «Додай ролі: admin і member. Перелічи кожну кінцеву точку і те, які ролі можуть її викликати».
• «Забезпеч на сервері, щоб користувачі могли читати і редагувати лише свої записи. Потім покажи, як ти це перевірив».
• «Додай скидання пароля з одноразовими посиланнями, які спливають за годину».
• «Обмеж кількість спроб входу».

Потім перевірте сам: створіть два облікові записи і спробуйте отримати доступ до даних одного, увійшовши під іншим. Посібник з додавання входу і контрольний список безпеки розкривають тему докладніше.

Автентифікація в Mythex

Mythex не надає вбудованого продукту автентифікації для користувачів вашого застосунку; ви обираєте підхід — електронну пошту і пароль, що зберігаються у базі даних вашого проєкту, або SDK хостингового провайдера — і просите агента його додати. Ключі провайдера зберігаються в секретах проєкту, а не в чаті. Це окремо від того, як ви входите в сам Mythex. Рецепт документації щодо додавання входу до застосунку містить стартовий промпт, який можна адаптувати, а що таке API пояснює, де розміщені ці серверні перевірки.

Запитання