Действительно ли вам нужно несколько арендаторов для управления вашей системой идентификации?

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

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

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

Logto — это облачное решение для идентификации, также существует решение с открытым исходным кодом (OSS) с тем же ядром, что и облачные службы для пользователей со специальными потребностями для проведения настройки. Сервис Logto построен на системе с несколькими арендаторами, где каждый пользователь Logto создает свою собственную учетную запись и может управлять несколькими арендаторами в учетной записи. Другие различные облачные сервисы идентификации также имеют аналогичную архитектуру, при этом каждая из облачных служб имеет свое собственное определение "арендатора", поэтому обсуждаемая в этой статье модель арендатора ограничена сценарием Logto, а у других поставщиков могут быть другие соответствующие концепции.

Стоит отметить, что в многопользовательской модели Logto, данные между арендаторами (вся информация о конечных пользователях) изолированы, поэтому пользователи Logto могут управлять данными учетных записей конечных пользователей в соответствии с их бизнес-потребностями в одной учетной записи Logto. Многие другие облачные сервисы идентификации могут поддерживать только наличие одной учетной записи с одним арендатором, что заставляет пользователей, которым нужно управлять несколькими арендаторами одновременно, часто переключаться между учетными записями, что приводит к плохому опыту.

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

Случай 1: Приложение напрямую предоставляет услуги конечным пользователям#

Модель идентификации в таких приложениях довольно проста. Возьмем, к примеру, приложение для потоковой передачи музыки — кроме админа (пользователь Logto “foo”, который является владельцем арендатора в данном случае, имеет административный доступ по умолчанию), есть только конечные пользователи.

В этом сценарии конечные пользователи могут быть разделены на три типа:

1. Пользователь бесплатного плана: Может слушать только бесплатную музыку
2. Пользователь платного плана: Может слушать бесплатную музыку и создавать свои собственные плейлисты
3. Премиум-пользователь: Помимо прослушивания бесплатной музыки и создания плейлистов, может также слушать музыку HiFi

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

Случай 2: Приложение платформы eCommerce#

Платформа, которая соединяет сторонних поставщиков услуг и конечных пользователей, что также является очень распространенной бизнес-моделью 2C на сегодняшний день. Существуют две группы пользователей, которых следует учитывать — используя приложение для электронной коммерции в качестве примера, это продавцы (поставщики услуг) и покупатели (конечные пользователи).

Здесь есть два способа построения модели идентификации:

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

2. Поместите покупателей и продавцов в двух разных арендаторов соответственно.

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

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

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

Если у продавцов есть много разных продуктов для управления, использование модели идентификации 2 и разработка более специализированного приложения для продавцов должно быть лучшим выбором. Модель 1 больше подходит для платформ, таких как eBay, где у продавцов не так много продуктов и им не требуется чрезмерно сложная функциональность управления продуктами.

Случай 3: Приложения, созданные IT-консалтинговой компанией#

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

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

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

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

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

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

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