Skip to main content

Plan your architecture

To establish best practices in design and plan your architecture, consider your needs from different perspectives. Focus on the end goal and workflow, not just the underlying technologies and features. Here are some key questions to guide and inspire you in building the ideal architecture for your product.

What is your business model, and who are the key parties and stakeholders involved?​

Generally, there are two main business models, B2C and B2B, each involving different parties in complex identity management scenarios. Understanding these key stakeholders helps you design systems that deliver a user-centered experience and address all aspects of identity management.

B2C​

In B2C applications, identity management is typically straightforward and usually involves just two parties.

Developers (You)​

This refers to Logto Console admins and collaborators — typically you and your development team — manage and secure the user identity pool and work directly with the identity database. You can directly manage customer identities in the Logto Console or do custom development using the Logto Management API.

Your consumers​

Your consumers are user identities stored in Logto’s core service and database. In a B2C model, consumers can manage their own authentication and personal information.

B2B​

In B2B applications, there is another layer and context introduced into this architecture. The business unit owner (or organization) controls who can access their instance, how they authenticate, and what they can do. The organization manages the identity of all end users who access their instance.

Developers (You)​

This still refers to Logto Console admins and collaborators. Although organization admins can manage identities, developers can still directly manage customer identities in the Logto Console or through custom development using the Logto Management API.

Your clients (Organization admins)​

Your clients are business units representing “organizations” in a multi-tenant app, for example, workspaces in Slack or Notion. Each workspace typically has multiple roles and one or more admins who manage employees or users. In the following content, we refer to people who CAN manage member identities as "organization admins."

Your client's staff, partners, or consumers​

These are end-user identities, referred to as “members” in the organization context, and can be managed within an organization. While these identities are separated by organizations, they are all aggregated under a single identity system.

In real-world scenarios, from a product perspective, these could be company staff, business partners, or even consumers associated with the organization.

Others​

Other models, like B2B2C, may arise from these two due to their complexity. However, the approach remains the same: all changes stem from the same core foundation.

In the next chapter, we’ll take a detailed look at these two common architectures and highlight the related features supported by Logto.

Distill your auth needs​

Once you understand the key users and parties involved in your tech and product design, consider the following questions to refine your identity architecture and determine your authentication needs and control level:

  1. What options do customers have for authentication and the sign-in experience? These usually depend on your business, acquisition strategy, and product needs.

    eg. What features are needed for my app? Social sign-in? Passwordless login?

  2. What level of control do you (developers) want over customer actions?

    eg. Can customers update and maintain their profile? Can customers turn on and off MFA on their own? Can they choose preferable sign-in methods?

  3. What types of customization would you like to delegate to organizations? These depend on your product’s domain and industry and your clients’ specific needs and may vary from one organization to another.

    eg. Should the sign-in experience vary for each organization? And if so, should the customization be limited to branding, or should it also include differences in the authentication flow?

  4. What level of control would you like your organization admins to have over their members' actions?

    eg. Should the organization admin be able to decide if MFA is required? Should the admin have the ability to change a member’s password?

Do you need a single universal identity system or multiple separate ones?​

Another key questions to keep in mind is to ask yourself whether you or a segment of your business or product needs one identity system or separate.

Typically, the answer is a single universal identity system, meaning you only need one Logto tenant (or one Logto admin console instance in OSS). Logto is built to support both multiple apps and multiple organizations within a single tenant. One production Logto tenant is usually sufficient for most needs. Here are some common scenarios you might face:

I would like to build a SaaS application with multi-tenancy​

If you are building a SaaS application with the concept of "workspace" or "organization" for each customer, you can use organizations to manage each customer's workspace within a single tenant.

In this case, a user can be a member of multiple organizations. For example, a user can have a personal workspace and join the company's workspace.

I have multiple applications​

With Logto, you can manage multiple applications within a single tenant regardless of

  1. The application's type (for example, web, mobile, desktop, etc.)
  2. The application use cases and functionalities (for example, driver app, hailer app, etc.)

I have multiple enterprise customers​

You can use organizations with enterprise SSO to manage multiple enterprise customers within a single tenant. By configuring enterprise SSO email domain settings and using the Just-in-Time provisioning feature, you can automate the process of users with enterprise SSO accounts joining or signing in to the appropriate organizations.