Designing your app architecture

Frontegg is designed to simplify how businesses handle access to their applications, offering multiple authentication options with great flexibility and customizable features to meet various business needs. Frontegg's model is built with three key players that utilize its services: Vendors, Tenants, and Users. Let's get to know each and the interplay within them.

Get to know the key personas

Before diving into each, here is a general overview of the main personas using Frontegg:

• Vendor: Vendors are considered super Tenants, with admin qualities and are the direct accounts under Frontegg. Vendors can configure and devise advanced security and authentication aspects for their customers (i.e., their tenants), and do so in multiple environments (development, staging, QA, and production). Vendors control advanced configurations and the visual interface of their tenants' login box— i.e., what their tenants see when logging in.
• Tenant: Tenants are the customers of Frontegg Vendors. Tenants can add and manage users via their Admin Portal view. Tenant configurations are devised by the vendors.
• Sub-tenant: Sub-tenants are tenants of Tenants and are part of a hierarchical business model that allows for sub-account management. Note that a vendor must enable sub-tenancy capabilities for its tenants. See Hierarchies (Sub-account Management) for more information.
• User: Users are end-customers of vendors and the direct users of tenants. When working in a hierarchical model, an admin user in tenant A, for example, may also be able to make changes in the sub-accounts of tenant A and their subset users. User Permission scope is defined by the user's Role.

Vendors

Frontegg Vendors refer to Frontegg's 'direct' customers. Vendors can configure settings in every environment, have the flexibility to add accounts, enable/disable features, set advanced system configuration e.g., JWT expiration, IP restriction, and more. Vendors can also enable/disable features for their tenant's usage, e.g., their tenants' ability to send user invitations, authenticate their users via social login methods, generate user tokens, etc.

Tenants and sub-tenants

📘

Important

Note that Tenants equal Accounts. A User must be a member of at least one account (Tenant).

Frontegg Tenants are accounts nested under Vendors. Vendors add users to tenants (accounts) via Frontegg's backoffice (in the Frontegg portal) or via APIs. Users can add additional users to their tenant (account) via the self-service (Admin portal).

While users are the direct customers of Tenants, Vendors control both tenant configuration as well as the entire hierarchy, down to the farthest end users.

Sub-tenants

Sub-tenants are nested within existing Tenants. Note that tenant users can have admin capabilities to control sub-tenants and their users. While it may sound complicated initially, the idea is to have the utmost flexibility to control and adjust the model to various use cases. Sub-tenants refer to the third layer of Tenants and onwards. Sub-tenancy can help intricate business models manage multiple accounts and user layers. In this hierarchical business model, the vendor, which stands atop all hierarchy layers, must enable the sub-tenancy capability for its tenants before they can add accounts under their scope. Learn more about facilitating sub-tenancy here.

Users

Users are the end-customers of Vendors and the direct customers of Tenants or Sub-tenants. Since the tenancy 'model' is built hierarchically, an admin user of Tenant A, for example, may also have permission to add/delete users nested under Tenant A's Sub-tenant. Users are defined by their Roles and associated Permissions.

👍

Users belonging to multiple tenants

Users can be associated with different tenants nested within the same vendor— while still maintaining their user ID and information accross all tenants.

Scopes of each persona

Vendor capabilities

• Designated APIs, dependent on creating a Vendor Token that must be used for these APIs.
• Multiple environment access and control. Advanced configurations (security, authentication, authorization, and more) can be configured for each environment for utmost control.
• Control over the entire cascade of Tenants and Users.

Tenant capabilities

• Tenant scope is defined by Vendor configuration.
• Admin portal configurations and user management.
• Multiple actions can be performed via the Frontegg Portal UI or via API.
• Ability to assign user roles and permissions.
• Ability to add sub-tenants as part of a multi-tenancy model (if enabled by vendor).
• Tenants use Tenant Tokens for performing API requests.

📘

Sub-tenant scope

Sub-tenant capabilities are identical to Tenant's, and are defined by the Vendor.

User capabilities

• Users are authorized or devoided from performing actions in your app according to their designated Permissions and Roles.
• User Tokens are used when performing user-related API requests.