Авторизація колись була складною частиною побудови веб-застосунку. Ви витрачали два тижні на хешування паролів, менеджмент сесій, верифікацію email, скидання пароля і rate limiting перш ніж писали бодай одну фічу. Потім через півроку розуміли, що пропустили CSRF-кейс — і вкусило.
Це більше не той світ, у якому ми. Для більшості проєктів питання вже не «як побудувати auth?». Це «який managed-сервіс використати?».
Цей пост — про той вибір. Три варіанти, що мають значення у 2026, що кожен робить добре, скільки коштує, і вимір, який більшість команд недооцінює: операції.
Три реальні варіанти
Для Next.js веб-застосунку реалістичні вибори:
- Clerk — повністю managed auth-as-a-service. Drop-in UI-компоненти, hosted user database, OAuth-провайдери преконфігуровані, MFA вбудовано.
- NextAuth (Auth.js) — opensource, self-hosted, бібліотечного стилю. Базу приносите ви. Вони роблять роботу з протоколом.
- Власне рішення — кастомний код, кастомні таблиці бази, кастомні флоу. Сучасні бібліотеки (Lucia, Better Auth) роблять це менш болючим, ніж раніше.
Є й інші (Auth0, Supabase Auth, Stytch, Firebase Auth, AWS Cognito). Кожен має нішу. Auth0, якщо ви ентерпрайз. Supabase Auth, якщо ви вже на Supabase. Stytch, якщо хочете passwordless-first. Firebase Auth, якщо ви в екосистемі Google. У нашій роботі ми рідко тягнемось до них, тому цей пост зосереджений на трьох, між якими ми реально обираємо.
Clerk: коли він правильний
Clerk дає вам повну auth-систему приблизно за годину. UI-компоненти для входу, реєстрації, профілю користувача, менеджменту організацій. OAuth-провайдери (Google, GitHub, Microsoft, Apple) працюють з коробки. MFA, скидання пароля, верифікація email — усе включено. Webhook-и для подій життєвого циклу користувача.
Компроміс:
- Ви платите за monthly active user. Безкоштовно до 10,000 MAU, потім $25/місяць плюс usage звідти.
- Дані користувачів живуть у інфраструктурі Clerk. У вас копії у вашій базі (синхронізовано через webhook), але Clerk — source of truth.
- UI-компоненти — їхні. Кастомізуються, але ви не володієте розміткою.
Clerk правильний, коли:
- Хочете запуститись швидко і не думати про auth після першого тижня.
- Ваша бізнес-модель дозволяє ціну за MAU (B2B SaaS з платними клієнтами зазвичай дозволяє; споживчі застосунки з free-тарифами зазвичай ні).
- Вам комфортно з тим, що third party тримає дані ваших користувачів.
- У вас немає специфічних UI-вимог, які компоненти Clerk не вміщують.
Ми обираємо Clerk для B2B SaaS-проєктів, де засновник хоче відвантажувати фічі, а не будувати auth. Сумарна ціна за перший рік зазвичай менша за те, що ми взяли б за побудову еквівалентного auth з нуля.
NextAuth: коли він правильний
NextAuth (ребрендований як Auth.js, але більшість досі називає NextAuth) — це бібліотека. Встановлюєте, конфігуруєте провайдерів, підключаєте database adapter, і у вас є auth. Дані користувачів живуть у вашій базі. Менеджмент сесій оброблений. OAuth-танець зроблено за вас.
Компроміс:
- Безкоштовно. Жодних usage-цін. Жодного vendor lock-in.
- Дефолти розумні, але не магічні. Доведеться сконфігурувати речі, які Clerk робить безкоштовно (зв'язування акаунтів, MFA, гранулярний контроль сесій).
- UI — ваш. NextAuth дає API, ви будуєте сторінку входу.
- Бібліотека змінювала форму між версіями. Міграції між major-версіями нас жалили.
NextAuth правильний, коли:
- Ціна має значення, і ваш MAU виштовхне Clerk за $200/місяць.
- Треба тримати дані користувачів у власній базі (комплаєнс, суверенітет даних або просто перевага).
- Ваші UI-вимоги не вписуються в компоненти Clerk, і вам швидше побудувати, ніж воювати.
- Ви ОК уважно прочитати доки і свідомо сконфігурувати.
Ми обираємо NextAuth для проєктів, де засновник технічний, чутливість даних користувачів середньо-висока, або де ціна Clerk за MAU домінувала б бюджет.
Власне рішення: коли воно правильне
У 2026 «своє» не означає писати хешування пароля з нуля. Це означає використовувати low-level бібліотеку (Lucia або Better Auth) і компонувати частини самостійно. Хешування, менеджмент сесій і OAuth — усе ще бібліотеки; ви просто не виносите загальний флоу назовні.
Компроміс:
- Максимум контролю. Форма auth точно відповідає вашому застосунку.
- Максимум відповідальності. Кожен edge-кейс — ваш. CSRF, session fixation, account takeover, race condition на паралельних входах.
- Найшвидший UX входу, бо нічого не має туди-сюди літати до вендора чи middleware.
Своє рішення правильне, коли:
- У вас специфічний auth-флоу, що не вписується в жодну бібліотеку. (Наприклад, magic-link з кастомною верифікацією домену, багатокроковий auth, прив'язаний до onboarding-у продукту.)
- Команда вже відвантажувала auth і знає edge-кейси.
- Продукт достатньо малий, щоб поверхня auth була обмежена.
Ми обираємо це рідко. Випадки, які виправдовують, зазвичай мають специфічні комплаєнс- або workflow-обмеження. Для більшості проєктів час, зекономлений з Clerk або NextAuth, вартий більше, ніж контроль, отриманий побудовою свого.
Операційний вимір
Фактор рішення, який більшість команд недооцінюють: що буде о 3 ночі, коли auth зламається?
З Clerk ви відкриваєте тікет у саппорті, і хтось у їхній команді це виправляє. Читаєте їхню status page. Чекаєте. Це нормально для більшості B2B-застосунків і нестерпно для будь-якого продукту, що продає себе на uptime.
З NextAuth ви дебажите самі. Бібліотека добре протестована, але взаємодії з вашою базою, OAuth-провайдером і платформою деплою — на вашій стороні. MTTR залежить від знайомства команди з бібліотекою і стеком.
Зі своїм рішенням ви теж дебажите самі, але принаймні знаєте код. Іноді це швидше, ніж розплутувати нутрощі бібліотеки. Часто ні, бо баг — у тій частині, на яку ви не дивились з моменту, коли її писали.
Для малої команди, що не 24/7 ops, «хтось інший це виправить» Clerk — це реальна цінність. Для більшої команди з on-call ротацією «ми володіємо кодом» NextAuth — реальна цінність. Для решти відповідь зазвичай — це що ви можете дебажити найшвидше, що зазвичай — що ви вже відвантажували раніше.
Матриця рішення
Ми використовуємо спрощену матрицю:
| Ситуація | Обрати |
| Соло-засновник, B2B SaaS, хоче відвантажувати | Clerk |
| Лін-команда, технічна, чутлива до ціни | NextAuth |
| Команда середнього розміру, важить суверенітет даних | NextAuth |
| Ентерпрайз-клієнт, комплаєнс-важкий | Auth0 або NextAuth на виділеній інфрі |
| Споживчий застосунок, високий free-tier MAU | NextAuth (ціна Clerk ламається) |
| Кастомний флоу, що воює з обома бібліотеками | Своє рішення |
| Ви ніколи раніше не відвантажували auth | Clerk (страховка має значення) |Це не вичерпно. Це звідки ми стартуємо, потім коригуємо під специфіку проєкту.
Пастка: обрати неправильно і мігрувати пізніше
Міграції auth болючі. Не неможливі, але болючі у тому сенсі, що «виправимо пізніше» насправді означає «житимемо з цим два роки».
Таблиця користувачів — рефересується звідусіль. Модель сесії переплетена з кожним захищеним маршрутом. Токени OAuth-провайдерів (для «увійти через Google»-флоу) зберігаються у форматах, специфічних для бібліотеки, яку ви використали.
Щоб мігрувати з Clerk на NextAuth, треба:
- Експортувати список користувачів.
- Змапити user ID Clerk до очікуваних ID NextAuth (або змінити кожен референс у вашій базі).
- Перевпровадити кожен UI, що використовував компоненти Clerk.
- Перевідавторизувати кожного активного користувача. Його існуюча Clerk-сесія стане недійсною.
Останній пункт — убивця. Примусова повторна авторизація означає тисячі користувачів, що б'ються об ваш екран входу в один день. Багато подумає, що сервіс зламано. Дехто відвалиться.
Порада: обирайте один раз, свідомо, з річним поглядом на проєкт. Міграція у перший рік — дорога. Міграція у третій рік — re-platform.
Нудна рекомендація
Для більшості B2B SaaS-проєктів, які ми відвантажуємо: Clerk у перший рік, з чітким оком на ціну за MAU.
Для більшості проєктів з тиском по ціні чи комплаєнсу: NextAuth з першого дня.
Своє рішення — для проєктів, де жодне з двох не пасує, що буває рідко.
Бібліотечна війна навколо auth здебільшого закінчена. Вибори хороші. Рішення — операційне більше, ніж технічне.
Якщо будуєте веб-застосунок і хочете розумний auth-вибір зі старту, подивіться, як ми працюємо із веб-застосунками. Підберемо auth-вибір під проєкт, а не проєкт під auth-вибір.