Як додати вхід до застосунку: паролі, магічні посилання, Google і ролі

Щоб додати вхід до застосунку, оберіть спосіб — електронну пошту та пароль, магічні посилання (одноразове посилання для входу, надіслане електронною поштою) або «Увійти через Google» — і реалізуйте його за допомогою перевіреної бібліотеки автентифікації чи хостингового провайдера, а не з нуля. Далі визначте, що може робити кожен тип користувачів (ролі), і забезпечте це на сервері для кожної сторінки та кожного запиту API. Сесії мають використовувати безпечні cookie, спливати з часом і коректно завершуватися під час виходу.

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

Спершу вирішіть: чи взагалі потрібен вхід?

Вхід додає тертя й відповідальності. Він потрібен, коли:

• У користувачів є приватні дані (їхні бронювання, документи, рахунки)
• Користувачі можуть змінювати речі, які бачитимуть інші
• Ви беретеся за доступ платно
• Різним людям потрібні різні дозволи (власник, персонал, клієнт)

Можливо, він не потрібен для маркетингового сайту, публічного каталогу чи форми, яка просто надсилає вам листа. Список очікування не потребує облікових записів; достатньо поля для електронної пошти.

Чотири поширені способи входу

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

Електронна пошта і пароль

Якщо ви пропонуєте паролі, ці вимоги обов'язкові:

• Хешуйте паролі повільним алгоритмом хешування. Рекомендації OWASP щодо зберігання паролів радять Argon2id, а як альтернативи — scrypt, bcrypt або PBKDF2. Ніколи не зберігайте паролі у відкритому вигляді чи з швидким загальним хешем.
• Скидання пароля використовує випадкове одноразове посилання, яке спливає, і надсилається на перевірену адресу.
• Не показуйте, які адреси мають облікові записи. «Якщо така адреса зареєстрована, ми надіслали посилання для скидання» краще, ніж «Облікового запису не знайдено».
• Обмежуйте частоту спроб входу та скидання, щоб уповільнити підбір паролів.
• Дозволяйте довгі паролі та менеджери паролів; не застосовуйте правил, які змушують до дивного поєднання символів.

Магічні посилання та одноразові коди

Магічне посилання — це посилання для входу, надіслане користувачеві електронною поштою. Клік по ньому входить в обліковий запис. Одноразовий код — та сама ідея, тільки його вписують, а не клікають.

• Посилання й коди швидко спливають і працюють лише один раз.
• Посилання має входити в обліковий запис на пристрої, де на нього клікнули, а токен не повинен залишатися в журналах або інструментах аналітики.
• Потрібна надійна доставка листів — див. як надсилати листи з вашого застосунку. Тестуйте в Gmail і Outlook та перевіряйте папки спаму.

Вхід через Google (та інші провайдери OAuth)

«Увійти через Google» використовує OAuth і OpenID Connect: Google підтверджує, хто користувач, і повідомляє вашому застосунку його електронну пошту та ім'я. Налаштування станом на вересень 2026 року виконується в розділі Google Auth Platform у Google Cloud Console:

1. Створіть або оберіть проєкт і заповніть сторінку Branding — те, що користувачі бачать на екрані згоди (назва застосунку, службова електронна пошта, логотип).
2. На сторінці Clients створіть клієнт типу «Web application».
3. Додайте authorized JavaScript origins та redirect URIs — точні адреси, де працює ваш застосунок і куди Google повертає користувачів після входу.
4. Збережіть ідентифікатор клієнта та секрет клієнта в секретах застосунку.

Що часто йде не так, за документацією OAuth від Google:

• redirect_uri_mismatch: адреса перенаправлення має збігатися точно, включно з http чи https, регістром і завершальним слешем. Додайте одну адресу для попереднього перегляду та одну для живого домену.
• Потрібен HTTPS: URI перенаправлення мають використовувати HTTPS, крім localhost під час розробки.
• Параметр state слід перевіряти при поверненні, щоб захиститися від міжсайтової підробки запитів. Хороші бібліотеки роблять це за вас.

Якщо ви запитуєте лише базову інформацію для входу (ім'я, електронну пошту, профіль), Google каже, що верифікація застосунку не є обов'язковою. Запит доступу до Gmail, Drive чи Calendar користувачів — інша справа, вона потребує верифікації.

Створити самостійно чи використати провайдера?

Перші два варіанти обидва розумні. Хостингові провайдери роблять більше за вас, але додають залежність і іноді беруть плату за активного користувача; актуальні ціни перевіряйте на їхніх сайтах. Бібліотеки зберігають усе у вашій базі даних, але залишають більше налаштувань, які треба зробити правильно. Що б ви не обрали, попросіть ШІ використати це, а не писати логіку паролів чи сесій вручну.

Ролі та дозволи

Вхід каже вам, хто людина. Дозволи визначають, що вона може робити. Спочатку тримайте це простим:

Правила, які важливіші за назви ролей:

• Перевіряйте на сервері щоразу. Приховання кнопки на сторінці не завадить комусь викликати API напряму.
• Прив'язуйте до власника. Учасник, який запитує «бронювання 123», має отримати його лише якщо воно його.
• Користувачі не можуть самі себе підвищити. Ігноруйте поля ролей, надіслані з браузера під час оновлення профілю.
• За замовчуванням — без доступу. Нові маршрути мають вимагати входу, якщо ви не вирішили інакше.

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

Безпека сесій

Після входу застосунок запам'ятовує користувача через сесію — зазвичай cookie. Рекомендації OWASP щодо управління сесіями радять:

• Cookie сесії з Secure (лише HTTPS), HttpOnly (недоступні для скриптів сторінки) і SameSite
• Новий ID сесії видається під час входу та знову, коли змінюються привілеї
• Тайм-аут бездіяльності та абсолютний максимальний термін дії, що забезпечуються на сервері
• Вихід, який завершує сесію на сервері, а не лише видаляє cookie
• Сесії анулюються, коли користувач змінює пароль

Зберігання токенів входу в локальному сховищі браузера часто зустрічається в навчальних матеріалах, але відкриває їх будь-якому скрипту, що працює на сторінці; безпечні cookie зазвичай кращий вибір за замовчуванням для веб-застосунків.

Промпт, що охоплює головне

Додай облікові записи користувачів до цього застосунку. Користувачі можуть реєструватися та входити з електронною поштою і паролем або через Google. Використовуй [бібліотеку або провайдера], а не власний код автентифікації. Хешуй паролі за допомогою Argon2id або bcrypt. Додай скидання пароля електронною поштою з одноразовим посиланням, яке спливає через годину. Зберігай сесії в безпечних cookie HttpOnly. Захисти /dashboard і кожен маршрут /api, щоб ними могли користуватися лише користувачі, які увійшли, і переконайся, що користувачі бачать лише власні проєкти. Додай роль «admin», яка бачить усіх користувачів; лише адміністратори можуть відкрити /admin, і це перевіряється на сервері.

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

Типові помилки у вході, створеному за допомогою ШІ

• Захист лише на сторінці. Сторінка перенаправляє користувачів, які не ввійшли, але API віддає дані будь-кому.
• Секрети в браузері. Секрети клієнта OAuth і адміністративні ключі провайдера автентифікації мають бути на сервері.
• Змішані попередній перегляд і живі адреси. Redirect URI Google або посилання в листі для скидання вказують на попередній перегляд, тож вхід ламається після публікації.
• Немає підтвердження електронної пошти. Будь-хто може зареєструватися як anyone@company.com. Перевіряйте пошту, перш ніж надавати що-небудь, прив'язане до цієї адреси.
• Тестування лише щасливого шляху. Спробуйте неправильні паролі, прострочені посилання та другий обліковий запис.

Додавання входу в Mythex

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

1. Оберіть підхід — наприклад, електронну пошту та пароль, які зберігаються у вашій базі даних, або SDK хостингового провайдера.
2. Якщо ви зберігаєте користувачів самі, застосунку потрібна база даних; попросіть її в чаті або використайте /database.
3. Помістіть ключі провайдера в секрети проєкту (/secrets або налаштування проєкту).
4. Використайте промпт на кшталт наведеного вище, потім протестуйте в попередньому перегляді. Для входу через Google додайте URI перенаправлення і для попереднього перегляду, і для опублікованої адреси.

Див. Add login to your app у документації. Якщо ви створюєте платний продукт, як створити MVP SaaS охоплює облікові записи й оплату разом.

Запитання