Построение многоарендного SaaS приложения: Полное руководство от дизайна до реализации

Как создаются такие приложения, как Notion, Slack или Figma? Эти многоарендные SaaS приложения кажутся простыми в использовании, но построить одно самому? Это совершенно другая история.

Когда я впервые подумал о создании такой сложной штуки, мой разум взорвался:

• Пользователи нуждаются в нескольких вариантах входа (электронная почта, Google, GitHub)
• Каждый пользователь может создавать и принадлежать нескольким организациям
• Разные уровни прав доступа в каждой организации
• Корпоративные организации, требующие автоматического присоединения для определенных доменов электронной почты
• Требования MFA для чувствительных операций
• ...

"Босс, давайте поговорим о дизайне продукта через две недели. Я сейчас в тупике."

Но когда я начал работать над этим, я понял, что это не так сложно, как кажется.

Я просто построил систему со всеми этими функциями МЕНЬШЕ ЧЕМ ЗА 2 ЧАСА!

Я покажу вам, как точно спроектировать и реализовать такую систему с нуля - и вы будете поражены, насколько это просто в 2025 году с современными инструментами и правильным архитектурным подходом.

Полный исходный код доступен в конце этой статьи. Давайте углубимся!

Мы начнем с AI-документарного SaaS-продукта под названием DocuMind.

DocuMind - это AI-документационный SaaS-продукт, разработанный с многоарендной моделью для поддержки индивидуальных пользователей, малых предприятий и корпораций.

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

Какие функции необходимы для SaaS-аутентификации и авторизации?#

Сначала давайте рассмотрим необходимые требования. Какие функции вам нужны?

Многоарендная архитектура#

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

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

Членство#

Участник - это временное понятие, используемое для указания статуса членства идентичности в организации.

Например, Сара регистрируется в вашем приложении, используя свою электронную почту, [email protected]. Она может принадлежать различным рабочим пространствам. Если Сара является частью Рабочее пространство A, но не Рабочее пространство B, она считается участником Рабочее пространство A, но не Рабочее пространство B.

Дизайн ролей и разрешений#

В многоарендной архитектуре пользователям нужны роли с определенными разрешениями для доступа к ресурсам своего арендатора. Разрешения - это детальный контроль доступа, который определяет конкретные действия, такие как read: order или write: order. Они определяют, какие действия могут быть выполнены с определенными ресурсами.

Роли - это набор разрешений, назначаемых участникам в многоарендной среде.

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

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

Поток регистрации и входа в систему#

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

1. Вход с электронной почтой и паролем: Традиционный метод входа в систему с использованием электронной почты и пароля.
2. Вход без пароля: Использование проверочных кодов электронной почты для легкого и безопасного доступа.
3. Управление учетной записью: Центр учетных записей, где пользователи могут обновить свою электронную почту, пароль и другие детали.
4. Вход через социальные сети: Варианты, такие как Google и GitHub, для быстрого входа.
5. Многофакторная аутентификация (MFA): Повышение безопасности, позволяя вход через приложения-аутентификаторы, такие как Duo.

Создание арендатора и приглашение#

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

Вот несколько типичных сценариев использования, которые вам нужно учитывать:

Это обычные сценарии, встречающиеся почти в каждом SaaS-приложении. Используйте их как справочник для вдохновения вашей продуктовой и дизайнерской команды и не стесняйтесь создавать свои собственные потоки по мере необходимости.

Техническая архитектура и проектирование системы#

Как только мы понимаем все требования к продукту, давайте перейдем к реализации.

Определение стратегии аутентификации#

Аутентификация выглядит страшно. Пользователи нуждаются:

• Регистрация/вход с электронной почтой и паролем
• Однокликовый вход с Google/Github
• Сброс пароля, когда они забывают
• Корпоративный вход для клиентов
• ...

Реализация только этих базовых функций может занять недели разработки.

Но теперь нам не нужно самостоятельно создавать это!

Современные поставщики аутентификации (я выберу Logto на этот раз) упаковали все эти функции для нас. Процесс аутентификации выглядит просто:

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

Установление многоарендной архитектуры#

Система организаций позволяет пользователям создавать и присоединяться к нескольким организациям. Давайте разберемся в основных взаимоотношениях:

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

Включение контроля доступа в многоарендном приложении#

Ролевой контроль доступа (RBAC) важен для обеспечения безопасности и масштабируемости многоарендных SaaS-приложений.

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

1. Единые определения разрешений: Разрешения определяются на системном уровне и применяются последовательно ко всем организациям, обеспечивая удобное и согласованное управление разрешениями
2. Шаблоны организаций: Предопределенные комбинации ролей и разрешений через шаблоны организаций, упрощая инициализацию организаций

Отношение разрешений выглядит следующим образом:

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

Мы спроектировали систему организаций и систему контроля доступа, и теперь мы можем начать строить наш продукт!

Технический стек#

Я выбрал удобный для начинающих, портативный стек:

1. Frontend: React (легко переносимый на Vue/Angular/Svelte)
2. Backend: Express (простая, интуитивно понятная API)

Почему разделение frontend и backend? Потому что это имеет четкую архитектуру, легко изучаемое и простое в переключении стека. И для поставщиков аутентификации я использую Logto в качестве примера.

И для следующих руководств, его шаблоны здесь работают с: Любым frontend, любым backend и любой системой аутентификации.

Добавление базового потока аутентификации в ваше приложение#

Это самый простой шаг. Нам просто нужно интегрировать Logto в наш проект. Затем мы можем настроить методы входа/регистрации пользователей в Консоли Logto в зависимости от наших нужд.

Установите Logto в ваше приложение#

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

В Консоли арендатора нажмите кнопку "Приложение" слева. Затем выберите React, чтобы начать создавать наше приложение.

Следуйте инструкциям на странице. Вы можете завершить интеграцию Logto примерно за 5 минут!

Вот мой код интеграции:

Вот полезный трюк: наша страница входа имеет обе кнопки - "Войти" и "Зарегистрироваться". Кнопка "Зарегистрироваться" ведет прямо на страницу регистрации Logto. Это работает через функцию first screen Logto. Она определяет, какой шаг аутентификационного потока пользователи увидят первым.

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

После нажатия на "Вход", вы попадете на страницу входа Logto. После успешного входа (или регистрации), поздравляем! В вашем приложении появился первый пользователь (вы)!

И вызовите функцию signOut из хука useLogto, чтобы выйти из системы, когда это нужно.

Настройка методов входа и регистрации#

В Консоли Logto нажмите "Sign-in Experience" в левом меню. Затем нажмите вкладку "Sign-up and sign-in". На этой странице следуйте инструкциям для настройки методов входа/регистрации в Logto.

А поток входа будет выглядеть так:

Включение многофакторной аутентификации#

С Logto, включить MFA просто. Просто нажмите кнопку "Multi-factor auth" в Консоли Logto. Затем включите на странице многофакторной аутентификации.

А процесс MFA будет выглядеть так:

Все так просто! Мы настроили сложную пользовательскую аутентификационную систему всего за несколько минут!

Добавление многоарендного опыта для организации#

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

Logto предоставляет встроенную поддержку многоарендности. Вы можете создавать любое количество организаций в Logto. Каждая организация может иметь нескольких участников.

Каждый пользователь может получить информацию о своей организации из Logto. Это позволяет поддерживать многоарендность

Получение информации о организации пользователя#

Чтобы получить информацию о организации пользователя из Logto, выполните эти два шага:

Объявите доступ к информации об организации в Logto Config. Это делается путем установки соответствующих scopes и resources.

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

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

Сейчас вы не создали ни одной организации. Пользователь также не присоединился ни к одной организации. Панель управления покажет "У вас нет ни одной организации".

Далее мы создадим для наших пользователей организацию и добавим их в нее.

Благодаря Logto, нам не нужно строить сложные организационные взаимоотношения. Нам просто нужно создать организацию в Logto и добавить в нее пользователей. Logto берет на себя всю сложность. Есть два способа создать организации:

1. Вручную создать организации через Консоль Logto
2. Использовать API управления Logto для создания организаций, особенно при разработке SaaS-процесса, позволяющего пользователям создавать свои собственные организации (рабочие пространства).

Создание организации в консоли Logto#

Нажмите кнопку "Организации" в левой части Консоли Logto. Создайте организацию.

Теперь у вас есть первая организация.

Далее, давайте добавим пользователя в эту организацию.

Перейдите на страницу сведений об организации. Переключитесь на вкладку Участники. Нажмите кнопку "+ Добавить участника". Выберите своего пользователя из левого списка. Нажмите кнопку "Добавить участников" в правом нижнем углу. Теперь вы успешно добавили пользователя в эту организацию.

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

Реализация функции самостоятельного создания организаций#

Создание организации в консоли недостаточно. Ваше SaaS-приложение нуждается в потоке, который позволяет конечным пользователям легко создавать и управлять своими рабочими пространствами. Для реализации этой функциональности используйте API управления Logto.

Для получения руководства ознакомьтесь с Взаимодействие с API управления, чтобы настроить API-связь с Logto.

Понимание этапов взаимодействия организации и аутентификации#

Возьмем в качестве примера поток создания организации. Вот как работает процесс создания организации:

Этот поток имеет две ключевые требования к аутентификации:

1. Защита API бекенд службы:
   • Доступ Frontend к API бекенд службы требует аутентификации
   • Конечные точки API защищены путем проверки токена доступа пользователя Logto
   • Обеспечивает доступ к нашим услугам только авторизованных пользователей
2. Доступ к API управления Logto:
   • Бекенд служба должна безопасно звонить API управления Logto
   • Следуйте Взаимодействие с API управления для настройки
   • Используйте аутентификацию машины-к-машине для получения учетных данных доступа

Защита вашего бекенд API#

Сначала создадим конечную точку API в нашей бекенд службе для создания организаций.

Наш API бекенд службы разрешает доступ только авторизованным пользователям. Нам нужно использовать Logto для защиты нашего API. Нам также нужно знать информацию текущего пользователя (такие, как ID пользователя).

В концепции Logto (и OAuth 2.0), наша бекенд служба действует как сервер ресурсов. Пользователи получают доступ к серверу ресурсов DocuMind с токеном доступа из frontend. Сервер ресурсов проверяет этот токен. Если он действительный, он возвращает запрошенные ресурсы.

Создадим ресурс API для представления нашей бекенд службы.

Перейдите в Консоль Logto.

1. Нажмите кнопку "API ресурсы" справа.
2. Нажмите "Создать ресурс API". Выберите Express в всплывающем окне.
3. Введите "DocuMind API" как имя API. Используйте "https://api.documind.com" как идентификатор API.
4. Нажмите создать.

Не беспокойтесь об этой URL идентификаторе API. Это просто уникальный идентификатор для вашего API в Logto. Он не связан с вашим фактическим URL бекенд службы.

Вы увидите учебник по использованию ресурса API. Вы можете следовать этому учебнику или нашим шагам ниже.

Создадим промежуточный requireAuth, чтобы защитить нашу конечную точку POST /organizations.

Для использования этого промежуточного слоя, нам нужны эти переменные окружения:

• LOGTO_JWKS_URL
• LOGTO_ISSUER

Получите эти переменные из OpenID Configuration tenant в Logto. Посетите https://<your-tenant-id>.logto.app/oidc/.well-known/openid-configuration. Вы найдете необходимую информацию в возвращенном JSON:

Теперь используйте промежуточный слой requireAuth в нашей конечной точке POST /organizations.

Это защищает нашу конечную точку POST /organizations. Только пользователи с действительными токенами доступа Logto могут получить к ней доступ.

Теперь мы можем получить токен от Logto в нашем frontend. Пользователи могут создавать организации через наш API бекенд службы с этим токеном. Также промежуточный слой дает нам ID пользователя, что полезно при добавлении пользователей в организации.

В коде frontend объявите этот ресурс API в конфигурации Logto. Добавьте его идентификатор в массив ресурсов.

Как прежде, пользователи должны снова войти в систему после того, как мы обновили конфигурацию Logto.

В панели управления получите токен доступа Logto, когда создаете организацию. Используйте этот токен для доступа к API бекенд службы.

Теперь мы можем правильно получить доступ к API службы бекенда DocuMind.

Вызов API управления Logto#

Давайте реализуем создание организации с использованием API управления Logto.

Как и в случае с запросами от frontend к API бекенд-службы, запросы от бекенд-службы к API управления Logto требуют токенов доступа.

В Logto, для токенов доступа мы используем аутентификацию машины-к-машине. См. Взаимодействие с API управления.

Перейдите на страницу приложений в Консоли Logto. Создайте приложение машины-к-машине. Назначьте ему роль "Доступ к управлению Logto API". Скопируйте URL токен-эндпойнта, ID приложения и секрет приложения. Мы будем использовать эти данные для получения токенов доступа.

Теперь мы можем получить токен доступа к API управления Logto с помощью этого приложения машины-к-машине.

Используйте этот токен доступа для вызова API управления Logto.

Мы будем использовать эти API управления:

• POST /api/organizations: Создание организации (см.: Ссылка на API создания организации)
• POST /api/organizations/{id}/users: Добавление пользователей в организацию (см.: Ссылка на API добавления пользователей)

Теперь мы реализовали создание организации через API управления Logto. Мы также можем добавлять пользователей в организации.

Давайте протестируем эту функцию на панели управления.

и нажмите "Создать организацию"

Создание успешно завершено!

Следующим шагом будет приглашение пользователей в организацию. Мы не будем реализовывать эту функцию в нашем учебнике пока. Вы уже знаете, как использовать API управления. Вы можете использовать этот Создание арендаторов и приглашение в качестве ссылки на дизайн продукта и легко реализовать эту функцию, следуя этой статье в блоге: Как мы реализуем пользовательскую совместную работу в многоарендном приложении.

Реализация контроля доступа в вашем многоарендном приложении#

Теперь давайте перейдем к контролю доступа организации.

Мы хотим достичь:

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

Давайте посмотрим, как реализовать эти функции.

Использование токена организации Logto#

Подобно токену доступа Logto, который мы упомянули ранее, Logto выдает токен доступа, соответствующий конкретному ресурсу, и пользователи используют этот токен для доступа к защищенным ресурсам в бекенд-службе. Соответственно, Logto выдает токен организации, соответствующий конкретной организации, и пользователи используют этот токен для доступа к защищенным ресурсам организации в бекенд-службе.

В приложении frontend мы можем использовать метод getOrganizationToken Logto, чтобы получить токен для доступа к конкретной организации.

Здесь organizationId - это идентификатор организации, которой принадлежит пользователь.

Прежде чем использовать getOrganization или любые функции организации, нам нужно убедиться, что область urn:logto:scope:organizations и ресурс urn:logto:resource:organization включены в конфигурацию Logto. Поскольку мы уже объявили эти параметры ранее, мы не повторяем это.

На нашей странице организации мы используем токен организации для получения документов внутри организации.

В этой реализации есть два важных момента:

1. Если organizationId, переданный в getOrganizationToken, не является идентификатором организации, к которой принадлежит текущий пользователь, этот метод не сможет получить токен, что гарантирует, что пользователи могут получить доступ только к своим собственным организациям.
2. При запросе ресурсов организации мы используем токен организации вместо токена доступа, потому что для ресурсов, принадлежащих организации, мы хотим использовать контроль прав организации, а не контроль прав пользователя (вы лучше это поймете, когда реализуем API GET /documents позже).

Далее мы создадим API GET /documents в нашей бекенд-службе. Подобно тому, как мы используем ресурс API для защиты API POST /organizations, мы используем индикационнойни только используем токен организации для защиты ресур са организации`.

Первым делом, добавим промежуточный слой requireOrganizationAccess для защиты ресурсов организации.

Затем используем промежуточный слой requireOrganizationAccess для защиты API GET /documents.

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

Некоторое программное обеспечение требует изоляции данных между организациями. Для дальнейшего обсуждения и реализации вы можете обратиться к статье в блоге: Реализация многоарендности с PostgreSQL: Изучите на простом примере из реальной жизни.

Реализация ролевого контроля доступа на уровне организации#

Мы реализовали использование токенов организации для доступа к ресурсам организации. Теперь мы реализуем контроль прав доступа пользователей в рамках организаций с использованием RBAC.

Предположим, DocuMind имеет две роли: Администратор и Сотрудник.

Администраторы могут создавать и получать доступ к документам, в то время как Сотрудники могут только получать доступ к документам.

Следовательно, наша Организация должна иметь эти две роли: Администратор и Сотрудник.

Администратор имеет как read:documents, так и create:documents разрешения, в то время как Сотрудник имеет только read:documents разрешение.

• Администратор
  • read:documents
  • create:documents
• Сотрудник
  • read:documents

Вот где вступает в действие функция шаблона организации Logto.

Шаблон организации - это шаблон модели контроля доступа для каждой организации: он определяет роли и разрешения, которые применяются ко всем организациям.

Почему шаблон организации?

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

Перейдите в Консоль Logto > Шаблоны организаций > Разрешения организации и создайте два разрешения: read:documents и create:documents.

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

Таким образом, мы создали модель разрешений RBAC для каждой организации.

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

Теперь у наших пользователей организации есть роли! Вы можете выполнить эти шаги через API управления Logto:

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

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

В конфигурации Logto frontend-кода нам нужно объявить разрешения, которые пользователи должны запросить в рамках организации. Давайте добавим read:documents и create:documents разрешения в scopes.

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

Затем в промежуточном слое requireOrganizationAccess на бенкенде добавляем проверку пользовательских разрешений.

Затем создаем API POST /documents и используем промежуточный слой requireOrganizationAccess с конфигурацией требуемых областей для защиты этого API и предыдущего API GET /documents.

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

На стороне frontend вы можете получить информацию о разрешениях пользователя, декодируя токен организации или вызывая метод getOrganizationTokenClaims Logto.

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

Добавление дополнительных функций многоарендного приложения#

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

Это все открытые функции, и вы можете найти больше информации об этих возможностях в документации Logto.

Итог#

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

Но посмотрите, что мы достигли:

• Полная система аутентификации с несколькими опциями входа и поддержкой MFA
• Гибкая система организаций, поддерживающая множество членств
• Ролевой контроль доступа в рамках организаций

И самое лучшее? Нам не пришлось изобретать колесо заново. Используя современные инструменты, такие как Logto, мы превратили то, что могло бы занять месяцы разработки, в дело нескольких часов.

Полный исходный код этого руководства доступен по ссылке: Образец многоарендного SaaS.

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

Исследуйте все функции Logto, от Logto Cloud до Logto OSS, на веб-сайте Logto или зарегистрируйтесь на Logto cloud сегодня.