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

Logto как раз про это: open-source инфраструктура для аутентификации и авторизации, то есть для входа в систему и проверки, что именно этому человеку можно делать. Вот репозиторий: https://github.com/logto-io/logto

Кому читать: если вы строите SaaS, B2B-продукт, AI-сервис или что-то с командами, организациями и ролями. Кому можно пропустить: если у вас простой pet project с одной таблицей users и кнопкой «войти через Google», тут, честно, будет многовато машины ради велосипеда.

Если просто

Logto — это не «ещё одна кнопка логина». Это слой, который берёт на себя всю скучную и опасную часть: как человек входит, как ему выдаются токены, как работают организации, SSO и роли.

Я сначала споткнулась о маркетинговую фразу про “auth infrastructure for SaaS and AI apps” и подумала: ну да, ещё одно «мы решаем всё». Но потом смотрю глубже — и да, там не просто витрина, а реально набор вещей, которые обычно собирают кусками и потом годами чинят.

Если по-человечески: вместо того чтобы самому городить OIDC, OAuth 2.1, SAML, MFA и RBAC, вы ставите готовую систему и подключаете к ней своё приложение. OIDC — это стандарт входа, OAuth 2.1 — стандарт выдачи доступа, SAML — старый корпоративный протокол, который до сих пор любят большие компании, а RBAC — это просто «роли и права», без лишней мистики.

Что это решает

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

Logto закрывает именно этот слой. Он обещает multi-tenancy, то есть поддержку нескольких организаций в одном продукте, enterprise SSO, RBAC, готовые sign-in flows и SDK для десятков фреймворков.

И вот тут, честно, мне это нравится. Не потому что «enterprise» звучит дорого, а потому что это как раз та часть, которую слишком легко недооценить. Все любят делать красивый экран логина. Никто не любит потом разбирать, почему у одного клиента права протекли в другую организацию. Ну и ну.

Как попробовать

Самый быстрый путь в README — Logto Cloud. Это managed-версия, где не надо сразу возиться с инфраструктурой. Для честной проверки это, пожалуй, лучший старт: зашли, покрутили флоу, поняли, ваше это или нет.

Если хочется open-source локально, есть два пути.

Первый — через Docker Compose:

curl -fsSL https://raw.githubusercontent.com/logto-io/logto/HEAD/docker-compose.yml | \
docker compose -p logto -f - up

Второй — через Node.js:

npm init @logto

Но тут важная оговорка: второй вариант в README прямо завязан на PostgreSQL. То есть это уже не «скачал и открыл», а нормальная девелоперская установка.

Для совсем быстрого щупания есть ещё GitPod, где обещают запустить OSS «за секунды». Я, если честно, к таким обещаниям отношусь с лёгким прищуром: иногда это правда быстро, а иногда «быстро» означает «потом ещё полчаса разбираешься, почему не тот URL открылся».

3 сценария с примерами

1. B2B SaaS с организациями и ролями Задача: у каждого клиента своя организация, у сотрудников разные права. Как применить: в Logto заводите tenants/organizations и назначаете RBAC-роль, например admin, billing, viewer. Что получится: один и тот же продукт, но без ручной путаницы в правах и без самописной логики «а кто из какой компании».

2. AI-платформа для команд Задача: пользователи работают не поодиночке, а командами, и нужно делить доступ к проектам, API и настройкам. Как применить: подключаете Logto как слой входа, а доступы строите на токенах и ролях. Что получится: можно быстрее дать SSO и управление доступами, не расписывая всё с нуля.

3. Внутренний сервис для нескольких отделов Задача: один сервис используют и маркетинг, и операционка, и техкоманда, а входы должны быть разные — где-то Google, где-то корпоративный провайдер. Как применить: через Logto настраиваете social login, enterprise SSO и нужные политики входа. Что получится: пользователям не надо заводить по три учётки, а вам — поддерживать три разных самописных костыля.

Где можно застрять

Вот тут без иллюзий. Logto выглядит дружелюбно, но это всё равно auth-инфраструктура. А auth — это тот самый класс вещей, где «чуть-чуть не так» потом вылезает в очень неприятный инцидент.

Во‑первых, понадобится понимание OIDC/OAuth/SAML. Да, в README пишут, что он снимает боль протоколов, но совсем не знание заменяет. Просто боль становится меньше, а не исчезает магически.

Во‑вторых, open-source тут не значит «нулевая цена». Самостоятельный запуск — это база, база данных, обновления, безопасность, мониторинг. Если у вас маленькая команда без бэкенд-опыта, можно красиво утонуть в эксплуатационных мелочах.

В‑третьих, issues там 183, и это не катастрофа, но и не игрушка в идеальном порядке. Плюс MPL-2.0 — лицензия нормальная, но всё же не тот случай, когда можно совсем не читать условия использования. Я бы не поленилась.

Кому это нужно

Это хороший вариант для команд, которые уже упёрлись в потолок простого логина.

Если вам нужны несколько организаций, корпоративный вход, MFA, социальный логин, роли и нормальная интеграция с современными фреймворками — тут есть смысл смотреть внимательно.

Ещё это явно сделано с прицелом на SaaS и AI-приложения, особенно где есть агентные сценарии и Model Context Protocol. Вот эта часть мне кажется любопытной: авторы явно пытаются поймать новую волну, а не просто переупаковать старый auth-сервер. И это, пожалуй, не пустой маркетинг — но проверить руками всё равно надо.

Кому это не нужно

Если у вас маленький сервис, где авторизация устроена просто и не планируется рост в B2B-сложность, Logto может оказаться тяжеловат.

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

И если задача звучит как «нам бы просто быстро сделать вход через Google», то давайте честно: тут не надо стрелять из пушки по кнопке.

Вердикт Веры

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

Но это не волшебная таблетка. Скорее аккуратно собранный костяк, который экономит очень много времени тем, кто действительно строит SaaS или AI-продукт с серьёзными сценариями доступа.

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

Что читать дальше

Материалы