Почему не стоит создавать собственную систему аутентификации: уроки из десятков интервью с клиентами

Аутентификация кажется тем, что можно сделать своими силами. Электронная почта, пароль, хэшируй, сравни при входе. Насколько сложно построить собственную систему аутентификации?

Можно. Вот в этом и ловушка.

Мы поговорили с десятками команд о самописных системах аутентификации. Почти все пришли к нам по одной причине: система тормозила развитие бизнеса.

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

Странность в том, что проблема не проявляется как сбой или авария. Люди спокойно входят в систему, и всё работает, пока одна бизнес-задача не блокирует движение: аудиторская проверка данных по безопасности, первый корпоративный клиент, поглощение компании или функция, охватывающая сразу два продукта.

Неделю назад все было "в порядке". Теперь следующий пункт в roadmap застрял за аутентификацией.

Главная ошибка авторских систем аутентификации — рассматривать их как обычную функцию. Реализовать можно в первый же день, но когда в систему пойдёт настоящий трафик, она переплетается с пользователями, организациями и правами доступа.

Аутентификация — это не функция. Это инфраструктура вашей идентификации.

За страницей входа скрывается полноценная модель идентификации#

Любая самописная система аутентификации стартует одинаково. Берём почту и пароль, хэшируем, сохраняем, сверяем при входе. Сорок строк кода, готово.

Проблемы начинаются после запуска. Боты бомбят endpoint регистрации — добавляете лимиты, CAPTCHA, отпечатки устройств. Утром перестают отсылаться SMS-коды — прикручиваете повторы и суточные ограничения. Затем приходят вещи посложнее: безопасный сброс пароля, MFA (двухфакторная аутентификация) и её восстановление, сессии, refresh-токены, и модель разрешений, намного сложнее, чем простой булевый is_admin.

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

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

Буквально всё, что вы пишете после, основывается на этих принятых решениях, и чем дольше система работает, тем труднее что-либо поменять.

Мы наблюдали это на примере одной компании: вертикальный B2B SaaS, двадцать лет на рынке, обслуживание офлайн-операторов. Свою аутентификацию они собрали больше десяти лет назад — отдельный вход для каждого клиента, проверки прав встроены в бизнес-модули. По тем временам казалось разумно.

Двадцать лет спустя они захотели, казалось бы, мелочь: одну общую страницу входа, где логином будет электронная почта. На деле это было не изменение страницы: проверки разрослись на сотни модулей, а объединить вход означало менять модель пользователей, организации, миграцию учетных данных и каждую границу разрешений. Никто не хотел брать это на себя, поэтому рефакторинг растянулся на годы.

Когда-то это выглядело как простая функция. На деле был заложен фундамент целой модели идентичности.

Когда бизнес развивается, самописная аутентификация начинает тормозить#

Честно говоря, собственная аутентификация часто служит долго. Она впускает пользователей, обновляет сессии, работает годами. Сложность подбирается постепенно, незаметно, и кажется, что всё под контролем.

Но "достаточно" — часто значит, что бизнес просто ещё не упёрся в потолок. Когда это случается, проблема уже не в самой аутентификации. Просто рядом изменился бизнес, и "достаточно" внезапно превращается в "мешает идти дальше".

Вот ситуации, с которыми в итоге сталкивается большинство продуктов при масштабировании. Они выглядят по-разному, но суть одна: бизнес вырос, а старая модель идентичности не успевает.

Корпоративные клиенты просят SSO#

Сценарий: клиент хочет входить через свой IdP, а ваша система аутентификации не понимает, что бывает "чужой провайдер идентичности".

Первый большой контракт, и вот приходит требований в procurement. Сперва SSO через Microsoft Entra или Google Workspace. Потом понадобится и SAML, и OIDC, потому что следующий клиент использует другое. Затем — SCIM, чтобы деплоить и лишать сотрудников доступа автоматически.

У каждого клиента свой набор: свои протоколы, маппинг полей, ротация сертификатов, структура организации, маппинг прав.

И почти ничто из написанного не переносится напрямую. Следующий клиент приносит новый IdP и новую конфигурацию, и всё начинается заново. SSO — это не фича, которую сделали однажды. Каждый крупный клиент требует полной реализации с нуля, и стоимость растёт с каждым клиентом.

Аутентификация перестаёт быть "пусть пользователь войдёт в ваш продукт". Теперь задача — "пусть ваш продукт подключается к корпоративной идентичности клиента". Совершенно разные задачи.

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

Когда принималось решение делать аутентификацию самим, об этом даже не думали.

Необходимость объединить разрозненную идентичность#

Сценарий: данные идентичности хранились фрагментированно — по организациям и продуктам, а по мере роста бизнеса появляется потребность в единой идентичности.

Уже упомянутая компания за двадцать лет столкнулась с этим при попытке объединить логины, и похожее встречается повсюду. Мы работали с платформой с девятью продуктами — результатом поглощений, каждый со своим auth и собственной базой пользователей.

Поглощение само по себе это не объединяет. С каждым новым продуктом вы наследуете ещё одну auth-стек, и для поддержки девяти параллельных стэков требуется отдельный штат.

Вопросы скапливаются. Один и тот же человек — это один пользователь в А и B, или два разных? Как сопоставить организации клиента между продуктами? Как дать разрешение на кросс-продуктовую функцию? Как при увольнении одного сотрудника лишить доступа ко всем девяти? Где хранить аудит?

Ни один auth по отдельности не сломан. Но вместе — это стена.

"Объединить идентичность" звучит как функция. В коде — это переписывание самой базы системы: что есть пользователь, что есть организация. Все функции сидят на старом определении, и изменить его — значит сдвинуть весь слой выше.

В эпоху ИИ доступ со стороны агентов и CLI от лица пользователя#

Сценарий: теперь в систему входят не только люди через браузер. Агенты, командные строки, скрипты действуют от чьего-то имени, а ваш auth" знает лишь одно: "человек заходит на страницу".

Агенту надо обратиться к внутренним сервисам за пользователя. MCP-серверу — безопасно раздавать защищённые ресурсы. CLI — получить доступ к учётным данным без браузера.

Все упираются в подобные вопросы: за какого пользователя выполняется запрос, к каким ресурсам есть доступ, на кого выписан токен, каков его scope, как его отзывать, чей аудит писать — пользователя или агента?

Старая auth не построена для таких клиентов. MCP требует OAuth для авторизации. CLI — либо логин через OAuth, либо bearer-токен, который можно отозвать в любой момент и который от имени пользователя. Всё это не было рассчитано на страницу входа.

Если ваша система auth рассчитывалась на вход только живого человека через страницу — теперь надо уметь обслуживать клиентов, действующих от его имени.

Долгосрочное обслуживание — самая дорогая часть авторской аутентификации#

В описанных выше случаях не происходит "краха auth". Всё функционирует. На деле это выглядит как мелкая функция, а когда начинаешь делать — оборачивается стратегией продукта, миграциями данных и работой с реальными клиентами.

MFA — самый яркий пример. На поверхности — "можно ли сделать ещё одну проверку после логина".

Через пару шагов: для каких организаций и пользователей обязательно, может ли админ навязать MFA всем членам, требует ли повторной проверки изменение платёжных данных или экспорт, как генерировать и сбрасывать recovery-коды, может ли техподдержка их сбросить, и принадлежит ли MFA пользователя SSO вам или IdP клиента? В итоге добавление MFA — это целый слой политики и безопасности.

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

Чем больше вы добавляете, тем ближе становитесь к тому, что пилите внутренний продукт по идентификации внутри своего продукта. Первая версия дёшёва — пара инженеров, пара недель. Потом вы кормите эту систему год за годом.

Скрытая плата: вы просто платите иначе#

Самая частая причина делать своё — стоимость, и она вполне оправдана.

Одна крупная ассоциация посчитала это пять лет назад. Сотни тысяч членов, а регулярно входили — несколько тысяч. Вендоры считали стоимость по количеству всех пользователей, итог включения выбивал все лимиты, и свое решение было дешевле. Тогда — правильное решение.

Через пять лет расчёты поменялись местами. Поддержка входа и безопасность уже стоили больше, чем покупка.

В первый год вы экономите видимый счёт, незаметно расходуя труд инженеров. На пятый год эта экономия становится задержками, техническим долгом, и поддержкой, от которой все шарахаются.

Свою auth никто не начисляет отдельным инвойсом. Вы платите человеческими месяцами, сдвигами сроков, переработкой, долгами по безопасности — и всем вниманием, что ушло не на основной продукт.

В итоге системой владеет горстка инженеров#

Тот ручной инженер с SSO — не исключение. Если держать свою auth долго, критические знания концентрируются у одного-двух человек: кто как настроен, какое поле нельзя трогать, зачем была старая миграция. Это редко бывает в документах, всё в чужой голове.

Когда человек в офисе — задачи двигаются. Когда нет — воронка enterprise-клиентов стопорится, и оказывается, что у самой важной инфраструктуры нет владельца, только "человек, который знает".

Даже если построить клиенту полный self-service для настройки SSO — это кажется уровнем зрелости, но сколько клиентов его использует? Мы видели сервис с 1,5 миллионами активных пользователей в месяц с целой платформой self-serve SSO ради пары дюжин клиентов.

Вы думали, что просто реализуете фичу. На самом деле вы построили отдельный внутренний продукт, расходы на который размазаны между дюжиной клиентов. Если идентификация — ваш продукт, это оправдано. Если нет — это самая чистая форма скрытой оплаты.

Где должны работать ваши инженеры?#

Вернёмся к тому SaaS за 20 лет. Это не слабые инженеры. Сохранить прикладной продукт 20 лет, реально понимая свой сегмент — достойно уважения.

И в этом проблема. Скажем прямо: вы хотите, чтобы эти инженеры вручную настраивали SSO для каждого клиента, вытаскивали 20 лет бизнес-логики из сотен модулей — или чтобы они развивали вашу отраслевую платформу?

Это не перфекционизм. Это вопрос стратегий и приоритетов. Если вы делаете биллинговый сервис, HRM, отраслевой SaaS или портал — никто из клиентов не заплатит вам ни рубля только за то, что вы написали свой OAuth-сервер.

В команде разработки биллинга сказали просто: самописный IdP работает, но главное — это стратегия. Не напишите многое на auth. Оставьте энергию для отработки бизнес-логики, а для остального берите лучшее, что есть на рынке.

Auth должен быть надёжен. Но "надёжен" — не значит "сделан своими руками". База, почта, облако — тоже критично надёжны, но зрелая команда не считает, что раз оно важно — всё непременно своё.

Для большинства продуктов аутентификация — главный компонент, но не точка дифференциации. Разве что идентификация — ваш бизнес, доверить ей сторонний продукт почти всегда выгоднее.

Когда всё-таки стоит писать свой auth?#

Всё сводить к крайности — "никогда не пишите свой auth" — тоже неверно.

На некоторых этапах создание своей системы (или её части) оправдано: внутренние демо, самые ранние прототипы, разовые тестовые проекты. А если у бизнеса настолько специфическая модель сложных разрешений, что platform-аутентификация не справляется — держите сложную логику у себя, а auth, сессии, SSO, MFA и юзердиректорию доверяйте платформе.

Просто следите за эффектом POC. Обычно так: двое за 6-8 месяцев делают прототип для интеграции с внешней системой. Всё не так уж плохо, по их словам — но оно не предназначено для масштабирования.

POC так легко превращается в долгосрочную архитектуру. Спустя полгода — "текущее решение", через два года — "уже легаси", через пять — "святыня, к которой боятся прикасаться". Лучшее время сбежать с собственного auth — до того, как он станет фундаментом продукта.

Так проходит грань: дело не в том, написали вы строчку кода по auth или нет, а в том, взяли ли вы на себя системную идентификационную инфраструктуру, оставили ли её на своей команде в долгую.

Дорабатывайте на грани. К базовому слою относитесь осторожно. И не задумываясь, не стройте себе из этого полноценную CIAM-платформу.

Если не писать самим — как выбрать auth-решение?#

Если решили не писать сами — возникает следующий вопрос: у кого покупать, и как выбирать?

Почти все зрелые решения уже закрывают нужные блоки: SSO, MFA, несколько организаций, единый вход, доступ агентов. Различия чаще всего даже не во "фичах".

Неочевидное, но ключевое для сравнения, — вот эти пункты. Они об одном: не выбрать решение, из которого”. Всё же нельзя будет выйти без боли.

• Используйте стандартные протоколы, а не выдуманные стэки одного вендора. OIDC, OAuth, RS256-подписанные JWT — то, что вы и так знаете. Читается из стандартного токена, не надо учить API очередного вендора.
• Держите настоящий запасной выход. Если решение open-source и реально self-hostable — вы всегда сможете уйти. (Обслуживать self-host самому — отдельная скрытая стоимость.)
• Не разрешайте биллингу читать вашу таблицу пользователей. Если цена считает всех зарегистрированных или месячных активных — таблица только растёт, в ней полно ушедших, и при масштабе это превращается в налог на развитие. Именно такое ценообразование однажды столкнуло ту самую организацию с построением своего решения.
• Данные не должны быть под замком. Должна быть возможность экспортировать данные пользователей в любой момент. Отдавая эти данные специалистам, вы защищаете себя от необходимости самим хранить личные данные и заботиться об их безопасности.

Честность: Logto — это продукт, который мы построили по этим пунктам. Open source, self-host, а также managed Cloud: хотите полностью без забот — используйте Cloud, хотите полный контроль — разверните open-source версию, и если решите перейти на что-то другое — дверь останется открыта.

Sign-in, MFA, SSO, RBAC работают из коробки на стандартном OIDC, а биллинг считает токены — платите только за реально используемое.

Есть и другие зрелые решения — и в аутентификации нет единственно правильного ответа. Если вы сравниваете — я написал целый гайд по выбору провайдера идентичности, пригодится.

Вывод: не перепутайте долговременную платформу идентификации с обычной функцией#

Сделать системy аутентификации самому — нормальное решение на старте. Загвоздка в том, что она вырастает в инфраструктуру.

Каждая новая задача быстро выносит это наружу: предприятия хотят SSO, безопасность требует MFA, продукт просит единый вход, несколько систем хотят интеграции, AI-агенты требуют доступ от лица пользователя. За каждой крошечной фичей стоят цепочки политик, а их обслуживание годами — это время, которое могло уйти в ваш основной продукт.

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

Скорее всего, идентификация — не главное в вашем бизнесе. Чем раньше это понять, тем быстрее вы сможете вернуть силы и ресурсы на продукт, который реально строите.

Вопросы и ответы#

Стоит ли вообще никогда не писать свой auth?#

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

В чем разница между аутентификацией и авторизацией?#

Аутентификация отвечает на "кто ты". Авторизация — "что ты можешь делать". В реальном SaaS эти вещи не разделить: пользователи, организации, роли, разрешения, сессии, токены, аудиты — всё это тесно связано. Поэтому если меняете компонент аутентификации — менять придётся намного больше, чем одну страницу входа.

Почему SSO для enterprise усложняет собственную аутентификацию?#

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

Мы годами работаем на самописном auth. Реально ли перейти?#

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