Better Auth vs Auth.js vs custom auth для команд Next.js

Почему этот выбор становится сложным для B2B-команд

Auth кажется простым, пока продукт маленький. Добавляете вход по email, возможно, вход через Google, и двигаетесь дальше. Но как только SaaS начинает продавать компаниям, этого уже недостаточно.

Бизнес-клиенты приходят со своими правилами. Им нужны чёткие границы tenant'ов, админские права, сценарии приглашений, audit logs и предсказуемый доступ, когда люди приходят в компанию или уходят из неё. Auth перестаёт быть просто экраном входа и начинает определять, как работает весь продукт.

Обычно давление появляется во время продаж. Один клиент просит SAML SSO. Другой хочет, чтобы пользователи могли входить только с одобренных доменов. Третий требует отдельных администраторов для каждого tenant'а и более строгих правил ролей для биллинга, поддержки и внутренних инструментов. Такие запросы нормальны для B2B SaaS, но они быстро вскрывают слабые решения.

Поэтому Better Auth vs Auth.js vs custom auth — это не просто сравнение инструментов. Это решение о продукте и операциях. Команда выбирает, сколько контроля ей нужно, сколько кастомной логики она готова поддерживать и сколько усилий хочет брать на себя в ближайшие несколько лет.

Неправильный выбор редко проваливается резко. Он создаёт медленное и дорогое трение. Инженеры постоянно чинят крайние случаи. Поддержка тратит время на исправление сломанных приглашений или доступа к tenant'ам вручную. Security review затягиваются, потому что правила живут в разрозненных callbacks и кастомных таблицах. Enterprise-сделки тормозятся, когда ответ про SSO звучит как «пока нет».

Обычно несколько вопросов быстро проясняют компромисс. Потребуются ли крупным клиентам SSO уже скоро? Нужны ли tenant'ам разные правила для доменов, ролей или жизненного цикла пользователей? Кто будет поддерживать auth после запуска, когда начнут накапливаться крайние случаи? Может ли команда позволить себе кастомную работу по безопасности каждый раз, когда продажи приводят более крупного клиента?

Если хотя бы на один из этих вопросов ответ «да», воспринимайте auth как продуктовую инфраструктуру, а не как второстепенную функцию. Команды, которые делают это заранее, обычно избегают болезненных переписываний позже.

Что на самом деле даёт каждый вариант

Большинство команд выбирают auth-инструмент не только по функциям. Они выбирают по уровню контроля, ожидаемой сложности клиентов и по тому, сколько часов готовы потратить на исправление крайних случаев позже.

Better Auth обычно сильнее всего ощущается там, где хочется как можно больше получить готовым на старте. Он даёт более чистую отправную точку для типичных задач вроде сценариев входа, обработки сессий и управления пользователями, не заставляя собирать всё с нуля. Для небольшой SaaS-команды это важно. Можно быстрее запускаться и не писать auth-код, которого клиенты даже не заметят.

Auth.js часто нравится командам Next.js, потому что хорошо вписывается в экосистему и оставляет пространство для настройки опыта. Если продукту в основном нужны вход через соцсети, вход по email и стандартная логика сессий, это может быть практичным средним вариантом. Проблемы начинаются, когда B2B-клиенты хотят необычные правила, поведение входа на уровне tenant'а или более глубокий контроль над тем, как identities сопоставляются с аккаунтами и ролями. Auth.js можно расширять довольно далеко, но в какой-то момент фреймворк начинает сопротивляться.

Custom auth даёт свободу, которой нет у библиотек. Вы сами решаете, как работают tenant'ы, как SSO подключается к каждому workspace, как роли наследуют права, как выглядят audit logs и как обрабатываются крайние случаи. Эта свобода помогает, когда auth — часть модели продукта, а не просто экран входа. Цена тоже проста: команда сама отвечает за каждую ошибку, миграцию, security review и ночной инцидент.

Размер команды меняет компромисс сильнее, чем многие основатели ожидают. Команде из 2–4 человек обычно лучше подходит Better Auth или Auth.js, потому что скорость важнее идеального контроля. Команда с одним сильным staff engineer или опытным CTO может безопаснее взяться за custom auth. Продукт, который продаётся более крупным компаниям, часто раньше упирается в кастомные требования, особенно вокруг B2B SSO в Next.js. А lean-команде без глубокой экспертизы в безопасности стоит дважды подумать, прежде чем писать auth с нуля.

Так что реальный выбор — это скорость сейчас против ответственности потом. Если auth — в основном вспомогательная функция, библиотека покупает вам время. Если auth определяет tenant control, договоры и enterprise-onboarding, custom-работа начинает выглядеть логичнее.

Как выбирать шаг за шагом

Начинайте с покупателей, а не с кода. Команды часто сравнивают библиотеки, читают документацию и тестируют API, а потом застревают позже, когда enterprise-сделки требуют SAML, tenant policies или отдельных правил входа.

Помогает простой процесс принятия решения:

1. Запишите 10–20 компаний, которым вы хотите продавать в ближайшее время. Отметьте, кому уже сейчас нужен B2B SSO в Next.js, кому это может понадобиться на этапе procurement, а кому это никогда не будет важно. Если даже несколько ближайших сделок зависят от SSO, воспринимайте это как продуктовую необходимость.
2. Составьте список tenant-правил, которые должен соблюдать ваш продукт. Простых ролей обычно недостаточно. Вам может понадобиться отдельный identity provider для каждого tenant'а, вход по домену, лимиты на сессии на уровне tenant'а, доступ только по приглашению, подтверждение новых пользователей админом или audit history.
3. Подсчитайте все auth-сценарии, которые вы уже поддерживаете или планируете поддержать в этом году. Включите вход по email, вход через соцсети, сброс пароля, magic links, impersonation для поддержки, переключение между tenant'ами, MFA, API tokens и SSO. Небольшие auth-стэки быстро усложняются, когда пять сценариев превращаются в девять.
4. Решите, кто будет отвечать за auth после запуска. Кто-то должен чинить баги со входом в воскресенье, разбирать странные ситуации с сессиями, читать документацию провайдеров и отвечать на security-вопросы клиентов.
5. Оцените каждый вариант по трём критериям: соответствие, скорость и поддержка. Соответствие — насколько хорошо решение подходит под ваши tenant-правила и enterprise-запросы. Скорость — как быстро команда сможет всё внедрить и протестировать. Поддержка — сколько времени уйдёт на исправления, обновления и расширение auth через полгода.

Растущие SaaS-команды часто учатся этому на практике. Сначала они выбирают базовый auth, потому что он запускается за неделю. Потом приходит первый более крупный клиент, просит SAML, более жёсткую изоляцию tenant'ов и audit logs, и дешёвый вариант перестаёт быть дешёвым.

Если оценки близки, выбирайте тот вариант, который команда сможет поддерживать, когда продукт удвоится по числу клиентов и путей входа. Обычно это безопаснее.

Где B2B SSO меняет решение

B2B-командам часто достаточно email-входа, magic links или соцсетей, пока первый крупный клиент не говорит: «Нам нужен SSO, иначе legal и security не одобрят контракт». Тогда auth из детали продукта превращается в блокер продаж.

В этот момент сравнение Better Auth vs Auth.js vs custom auth перестаёт быть простым выбором разработчика. Вы уже не просто выбираете сценарий входа. Вы решаете, насколько быстро команда сможет сказать «да» Okta, Microsoft Entra ID, Google Workspace или другому identity provider без недель лишней работы.

SAML и OIDC меняют масштаб задачи

С OIDC в современных приложениях обычно проще работать. SAML по-прежнему часто встречается в крупных компаниях, и он приносит больше настройки, больше крайних случаев и больше тикетов в поддержку. Если среди ваших клиентов есть компании с IT-управлением, закладывайте, что важны будут оба варианта.

Инструмент, который хорошо обрабатывает app sessions, всё равно может оставить пробелы в enterprise SSO. Задавайте простые вопросы. Может ли он поддерживать отдельный identity provider для каждого tenant'а? Может ли он сопоставлять пользователей с нужным workspace? Сможет ли команда разбирать неудачные входы, не читая сырой XML ночью? Если ответы расплывчатые, поддержка потом обойдётся дороже.

Custom auth даёт максимум контроля, особенно если у каждого tenant'а свои правила, claims или логика работы с доменами. Но он же даёт и максимум текущей работы. Библиотеки уменьшают эту нагрузку только тогда, когда их SSO-путь действительно совпадает с тем, что будет спрашивать ваш sales pipeline.

JIT-настройка часто застаёт команды врасплох

Just-in-time user setup звучит как мелкая деталь, но на самом деле определяет всю модель доступа. Когда пользователь впервые входит через SSO, приложению может понадобиться создать аккаунт, привязать его к правильному tenant'у, назначить роль по умолчанию и решить, кто сможет приглашать других.

Такая логика быстро становится сложной. Одно неверное правило по домену может отправить пользователя не в тот workspace. Одна слабая роль по умолчанию может открыть данные, которые должны оставаться приватными.

Многие SaaS-команды откладывают SSO, потому что о нём просит только один потенциальный клиент. Через шесть месяцев ещё три клиента просят то же самое, в продукте уже накопились сложные tenant-правила, и теперь SSO занимает больше времени и стоит дороже. Если enterprise-сделки входят в ваш план, обычно дешевле проектировать SSO заранее, даже если вы не включаете его для всех клиентов на старте.

Контроль tenant'ов важнее, чем сам вход

Большинство B2B-продуктов ломаются не на входе. Проблемы начинаются позже: когда один человек работает в двух компаниях, администратор отзываeт доступ или клиент хочет, чтобы все пользователи с одного email-домена автоматически попадали в нужный аккаунт.

В таком выборе контроль tenant'ов важнее, чем сам экран входа. Auth-библиотека может доказать, кто такой пользователь. Но ваш продукт всё равно должен решить, что такое tenant, кто к нему относится и кто может менять доступ.

Начинайте с чистой модели в данных. Пользователь — это человек. Компания — это tenant. Workspace — это более маленькая область внутри tenant'а, если она вам нужна. Membership связывает пользователя с компанией или workspace через роль.

Такое разделение экономит много боли в будущем. Если Мария работает с двумя клиентскими аккаунтами и использует один email для обоих, вы можете хранить одну identity и две отдельные membership-связки. Если же связывать identity и компанию напрямую, крайние случаи быстро начнут накапливаться.

Держите tenant policy в одном месте. Правила по доменам, приглашениям, проверке ролей и решениям о доступе лучше хранить в общем backend-коде и понятных таблицах, а не размазывать по случайным страницам и API-обработчикам. Одно и то же правило должно работать в интерфейсе, API и фоновых задачах.

Решите несколько правил заранее: кто может приглашать участников, может ли компания ограничивать доступ по email-домену, может ли один пользователь входить в несколько компаний, что происходит, когда админ меняет или удаляет роль, и какие действия вы записываете в audit log.

Audit logs важнее, чем многие команды ожидают. Когда меняется доступ, клиенты хотят знать, кто сделал изменение, когда это произошло и какой была старая роль. Если добавить это позже, обычно вы упускаете первые важные инциденты.

Для большинства команд Better Auth или Auth.js вполне достаточно для нормального входа. Tenant control обычно должен жить в вашей базе данных и в backend-правилах. Custom auth имеет смысл только тогда, когда правила для tenant'ов настолько необычные, что библиотека постоянно мешает. Во всех остальных случаях лучше упростить auth и вложиться в модель tenant'ов.

Как на самом деле выглядит стоимость поддержки

Работа над auth не заканчивается в момент, когда вход наконец заработал. Сначала идёт время на настройку: провайдеры, сессии, middleware, письма, tenant-правила и админский доступ. Потом начинается постоянная стоимость. Каждое новое изменение продукта в какой-то мере затрагивает auth, и кто-то должен быть на связи, когда вход ломается после обновления фреймворка или изменения провайдера.

Здесь разница между вариантами становится особенно заметной. Better Auth и Auth.js обычно экономят время на старте, потому что дают типовые сценарии из коробки. Custom auth даёт полный контроль, но команда отвечает за каждую движущуюся часть ещё много месяцев после релиза.

Самые трудоёмкие вещи обычно не связаны с самим экраном входа. Это приглашения, которые истекли в неподходящий момент или попали в spam, сброс пароля, который ломается на мобильных, объединение аккаунтов, когда пользователь присоединился по приглашению, а потом вошёл через Google, переключение tenant'ов для людей из двух компаний и изменения ролей, которые должны применяться сразу.

Для каждого пути нужны тесты, и не один. Нужны happy path, истёкшие ссылки, дубликаты аккаунтов, отозванный доступ, неправильный tenant и восстановление после клика по старому письму. Если команда поддерживает B2B SSO в Next.js, добавляйте ещё и особенности SAML и OIDC, сопоставление claims и тикеты от клиентов, у которых identity provider работает немного иначе.

Шестимесячный взгляд обычно показывает правду лучше, чем первый релиз. Команда может сэкономить неделю, быстро запустив auth, а потом следующие полгода чинить баги с сессиями, переписывать логику приглашений и заново тестировать каждый сценарий после обновления фреймворка. Вендоры меняют API. Браузеры ужесточают правила cookie. Даже медленно меняющиеся стандарты всё равно создают работу по доработке.

Полезно простое правило. Если продукту нужны обычный вход, стандартные роли и один-два провайдера, библиотека часто помогает держать стоимость поддержки auth низкой. Если вам нужен глубокий контроль tenant'ов, кастомные правила онбординга или необычное поведение enterprise SSO, закладывайте постоянную работу над auth как над любой другой частью продукта. Потому что именно ею он и становится.

Простой пример для растущего SaaS

Команда из шести человек запускает Next.js-продукт с входом по email, сбросом пароля и одной общей моделью workspace. Этого хватает для первых 20 клиентов. Никто не просит SSO, а tenant-правила остаются простыми, потому что все аккаунты работают одинаково.

Потом появляется крупный потенциальный клиент. Он хочет, чтобы сотрудники входили через свой корпоративный identity provider, и чтобы любой пользователь с email вида «@company.com» автоматически попадал в нужный tenant, а не создавал отдельный личный аккаунт. Задача меняется по форме. Вход уже не просто вход. Теперь он связан с привязкой к tenant'у, админскими правилами и контролем доступа.

Через месяц другой клиент просит более жёсткие ограничения. Их админ хочет подтверждать участников до выдачи доступа. Им также нужен понятный audit trail для приглашений, смены ролей и событий входа. Патчи начинают выглядеть дорого. Команда может продолжать добавлять условие за условием, но каждый новый enterprise-запрос повышает шанс получить неаккуратный код и странные крайние случаи.

Именно здесь спор перестаёт быть спором о библиотеках и становится продуктовым решением. Если команда продолжает латать систему, изначально построенную только для простого входа по email, очень часто ей всё равно приходится всё перестраивать под давлением.

Для большинства растущих B2B-продуктов более безопасный путь выглядит так:

• Оставьте текущую auth-библиотеку, если базовый вход уже работает.
• Перенесите tenant-логику в собственную модель приложения как можно раньше: организации, роли, владение доменом и audit-события.
• Добавляйте SSO для каждого tenant'а отдельным слоем, а не смешивайте его со всеми сценариями входа.
• Переписывайте весь auth-стек только если вашему продукту нужны необычные правила идентификации или auth — это часть того, что вы продаёте.

Такой средний путь сильно снижает боль. Вы не делаете полный rewrite слишком рано, но и не делаете вид, что одна система входа для отдельных пользователей сможет бесконечно обслуживать multi-tenant auth.

Хорошая проверка очень простая: если два enterprise-клиента просят разные правила доступа, ваш продукт уже перерос мышление в стиле «просто добавим ещё один callback».

Ошибки, которые команды повторяют снова и снова

Многие команды начинают с базового входа и считают, что остальное подождёт. Для демо этого хватает. Но всё начинает трескаться, когда в продукт приходит вторая компания и просит SSO, отдельных админов или более строгие правила доступа.

Одна частая ошибка — считать, что роли пользователей и границы tenant'ов это одно и то же. «Admin» и «member» говорят только о том, что человек может делать. Они не говорят, какой компании принадлежат данные. Если приложение проверяет роли, но не проверяет membership на уровне tenant'а при каждом чтении и записи, одна неточная выборка может показать записи другого клиента.

Команды также разбрасывают auth-логику по страницам, API routes, server actions и cron jobs. Потом у каждой функции появляются свои правила. Интерфейс что-то разрешает, API запрещает, а фоновые задачи вообще игнорируют проверку. Лучше держать проверки сессий, определение tenant'а и правила доступа в одном общем слое. Иначе маленькие баги быстро превращаются в проблемы с доступом.

Связывание аккаунтов и приглашения тоже доставляют больше боли, чем многие ожидают. Один человек может зарегистрироваться через Google, получить приглашение в workspace по email, а потом позже войти в ту же компанию через SSO. Если эти identity не объединяются аккуратно, люди теряют доступ, создают дубликаты аккаунтов или попадают не в тот tenant.

SSO — ещё одна ловушка. Команды часто выбирают решение, которое работает для входа по email и, возможно, для соцсетей, а потом предполагают, что позже просто добавят SAML или OpenID Connect. В B2B SaaS «позже» обычно наступает после звонка с продажами, когда реальному клиенту это нужно прямо сейчас. Неудачное время, чтобы обнаружить, что ваша модель пользователей не умеет вход по домену, отдельные провайдеры для каждого tenant'а или just-in-time provisioning.

На раннем этапе также часто игнорируют работу поддержки. После релиза auth создаёт стабильный поток неудобных случаев: приглашение истекло после того, как пользователь уже создал аккаунт; один человек принадлежит двум компаниям; компания меняет email-домен; владелец закрывает доступ всей admin-команде; вход через SSO проходит, но привязка к tenant'у ломается.

Именно здесь многие команды неверно оценивают стоимость. Код — это только часть счёта. Большая часть затрат часто появляется позже: в поддержке, исправлении крайних случаев и аккуратных миграциях под давлением.

Короткий чек-лист перед тем, как выбрать

Плохой выбор auth редко ломается в первый день. Он ломается через три месяца, когда потенциальный клиент просит SSO, tenant хочет собственные правила доступа, или команда тратит спринт на исправление приглашений и сессий вместо того, чтобы выпускать продукт.

Используйте этот чек-лист перед финальным решением. Если хотя бы на два или три пункта ответ «да», самый дешёвый на вид вариант может очень быстро перестать быть дешёвым.

• Понадобятся ли реальному клиенту в этом квартале SAML, вход по домену или SCIM?
• Нужны ли вашим tenant'ам разные правила для membership, сессий, подтверждений или доступа к данным?
• Есть ли у кого-то в команде время отвечать за auth не только на запуске, но и годами?
• Учли ли вы время на тестирование крайних случаев, а не только на написание кода?
• Создаст ли ваше решение ручную работу во время онбординга или security review?

Если продукт ещё на ранней стадии и у большинства tenant'ов одни и те же правила, библиотека обычно даёт достаточно. Если контроль tenant'ов — это часть самого продукта, вы можете перерасти простой путь раньше, чем ожидаете.

Команды часто упускают ещё одну стоимость: боль от миграции. Переход от базовой схемы к более строгой позже означает очистку данных, изменение сессий, сопоставление пользователей и коммуникацию с клиентами. Обычно это случается в самый неудачный момент — как раз тогда, когда начинают появляться более крупные сделки.

Если один enterprise-запрос может изменить вашу roadmap, выбирайте вариант, который оставляет эту дверь открытой.

Что делать дальше продуктовой команде

Если вы застряли между Better Auth, Auth.js и custom auth, не пытайтесь выбрать идеальную систему на все будущие сделки. Выбирайте ту, которая соответствует ближайшим 12 месяцам продуктовой работы, давлению со стороны продаж и возможностям команды.

Небольшая команда с быстрым roadmap обычно получает больше пользы от инструмента, который достаточно хорош сейчас и который легко менять позже. Команде, которая уже продаёт крупным компаниям, может понадобиться более строгий контроль tenant'ов раньше, даже если настройка займёт больше времени.

Запишите текущие границы до начала работ. Этот шаг сильно снижает хаос, потому что auth растёт через исключения, а исключения быстро дорожают.

Простой стартовый список может выглядеть так:

• Мы поддерживаем только одну конфигурацию identity provider на tenant, а не много.
• Мы пока не поддерживаем SCIM.
• Мы не делаем отдельные сценарии входа для каждого клиента.
• Мы не будем строить тонкие правила для tenant'ов в v1.
• Мы пересмотрим это решение через 90 дней.

Последний пункт важнее, чем многие думают. Поставьте реальную дату в календарь. К этому моменту вы уже будете понимать, действительно ли разговоры с клиентами толкают вас к более глубокому B2B SSO в Next.js или более простой путь всё ещё работает.

Полезно также заранее определить сигналы для пересмотра. Например: два enterprise-клиента просят SAML, один клиент просит роли, управляемые на уровне tenant'а, или слишком много часов уходит на крайние случаи auth в каждом спринте. Чёткие триггеры лучше, чем туманное беспокойство.

Если команда по-разному смотрит на этот выбор, внешний взгляд может сэкономить время. Oleg Sotnikov at oleg.is работает Fractional CTO и startup advisor, и такой архитектурный разбор хорошо подходит для этой роли. Краткий аудит вашей auth-модели, tenant-дизайна и вероятной стоимости поддержки обойдётся намного дешевле, чем полная переделка после того, как продажи уже пообещали функции, которые ваш auth-слой не умеет поддерживать.

Выберите путь, зафиксируйте ограничения и назначьте дату пересмотра уже сейчас. Так у команды появится решение, под которое действительно можно выпускать продукт.