Ты можешь сделать свою аутентификацию за день. Вот в чем ловушка.

Десятки команд B2B рассказали нам одну и ту же историю. Всё начинается с простой страницы входа. Затем через неё идет реальный трафик, и она незаметно становится инфраструктурой идентификации: основой, на которой стоит весь твой продукт.

Начни с Logto бесплатно

Связаться с нашей командой

Выглядело как функция. Оставило целую модель идентификации.

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

Первый день: сорок строк кода

Email, пароль, захешировать, сохранить, сравнить при входе. Просто и готово.

Вот почему все начинают именно здесь, и почему аутентификация кажется чем-то, что можно сделать за один вечер.

Двести дней: невидимая модель идентификации

Кто считается пользователем. К какой организации он принадлежит. Какой сеанс всё ещё действителен. Как отозвать доступ.

Ограничения скорости, MFA и процессы их восстановления, сессии, refresh-токены, модель организации, которая гораздо сложнее, чем просто is_admin. Каждый твой ответ превращается в правило, по которому теперь живёт продукт.

Пятый год: фундамент, к которому не подступиться

Поменять страницу входа "на бумаге" означало переписать весь фундамент идентификации в коде.

Один SaaS-проект с историей в 20 лет пытался перейти на email в качестве логина. Проверка прав находилась в сотнях модулей. Никто не решился одобрить, и всё тянулось, пока не стало невозможно продолжать.

Самописная аутентификация работает — пока не меняется бизнес

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

Крупные клиенты просят SSO

Появляется первая крупная сделка, и отдел закупок требует SSO через свой Entra или Google Workspace. Потом и SAML, и OIDC — ведь у следующего клиента всё иначе. У каждого клиента — свой подход к идентичности, и почти никакая работа не переиспользуется.

Разные протоколы, структуры полей и смена сертификатов для каждого клиента
SSO не делается раз и навсегда. Ты переделываешь это для каждого нового энтерпрайза
Это незаметно становится рутиной, которую понимает только один инженер

Узнать больше

Разрозненная идентификация теперь должна стать единой

Разделено по организациям, разделено по продуктам, часто ещё и унаследовано после поглощений. “Унифицировать идентификацию” звучит как функция, но по факту — это переписать, что считается пользователем и организацией.

Один email может принадлежать нескольким организациям? Как мигрировать старые логины?
Девять продуктов после поглощений — девять стэков аутентификации работают параллельно
Нужно сразу отозвать доступ у ушедших во всех системах и провести аудит в одном месте

Узнать больше

AI-агенты и CLI начинают работать от имени пользователя

Это уже не просто люди в браузере. Агенты, MCP-серверы и командные строки тоже действуют от имени пользователя. А твоя аутентификация умеет только вход по странице.

Кому выдан токен, с каким скоупом и для какой аудитории?
Дай доступ только одному инструменту или части данных, чтобы потом можно было отозвать
Доступ MCP и CLI строится на OAuth, а не на форме входа

Узнать больше

Настоящие затраты не в разработке. А в том, чтобы поддерживать это годами.

Первая версия дешева: несколько инженеров, несколько недель — и готово. Но потом ты кормишь это каждый год временем инженеров, которое должно было идти на основной продукт.

Счёт остался, только платить приходится иначе

Ты никогда не получишь счет на “аутентификацию”.

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

Всё держится на одном-двух людях

Вся критическая инфа — в голове, а не в документации.

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

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

Ни один клиент не заплатит тебе больше только за то, что ты написал свой OAuth-сервер.

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

Если не писать своё, как выбрать готовое решение?

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

Стандартные протоколы, а не выдуманный стэк

OIDC, OAuth и JWT на RS256 — ты это уже знаешь. Читай claims прямо из стандартного токена, не надо учить чужие API.

Дверь, через которую реально пройти

Если открытый исходный код и self-hosting — ты можешь уйти когда захочешь. Не меняй кастом на то, из чего не сможешь выбраться.

Биллинг, который не отслеживает таблицу пользователей

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

Твои данные всегда доступны

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

Аутентификация вряд ли — ядро твоего бизнеса. Относись к ней так.

Logto — open source, можно развернуть самому, также есть облако. Вход, MFA, SSO и RBAC работают сразу на стандартном OIDC. Оплата по токенам, и в любой момент ты можешь уйти.

Начните бесплатно

Связаться с нами

Часто задаваемые вопросы

Значит ли это, что никогда не стоит писать свою аутентификацию?

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

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

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

Почему корпоративное SSO усложняет самописную аутентификацию?

Корпоративное SSO означает, что твой продукт должен интегрироваться с системой идентификации клиента. У каждого — свой IdP, протокол, поля claims, сертификаты и структура организаций. Подключить первого клиента — это не сделать copy-paste для остальных. Чаще это становится ручной работой, которую понимает только один инженер.

Мы пользуемся своей системой много лет. Можно ли мигрировать?

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

Почему AI-агенты и MCP — новый источник нагрузки на аутентификацию?

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