Project AuthenticationLogin Definition

Login Definition

LoginDefinition

MPO Version: 1.3.0

Defines the core login architecture of the project, including the user and tenant structures that underpin authentication and access. These settings enable Mindbricks to generate a built-in 'auth' service tailored to your data model, supporting user registration, login, permissions, and optional multi-tenant behavior.

interface LoginDefinition = {
  userSettings : LoginDefUserSettings;
  tenantSettings : LoginDefTenantSettings;
}
FieldDescription
userSettingsDefines how the built-in user object is configured and authenticated within the project. While the user data model is fully managed by Mindbricks, this setting allows you to control the primary login identifier (email, mobile, or both), secondary identifier presence, super admin credentials, registration behavior, user group support, and verification requirements. These settings shape how authentication flows and access are handled at the user level.
tenantSettingsConfiguration for multi-tenant applications, including tenant object definitions and their relationship to users and user groups. When enabled, this isolates resources by tenant and supports tenant-scoped access control. Omit this section for single-tenant projects.

LoginDefUserSettings

MPO Version: 1.3.0

Defines how users are stored, managed, and authenticated within the project. This includes the primary login identifier configuration (email, mobile, or dual), secondary identifier presence rules, super admin credentials, email and mobile verification settings, public registration policies, and whether user groups are active. This structure governs the behavior and structure of the user service's primary data model.

interface LoginDefUserSettings = {
  primaryLoginIdentifier : PrimaryLoginIdentifier;
  superAdminIdentifier : String;
  superAdminPassword : String;
  userNameType : UserNameType;
  superAdminData : DataMapItem[];
  userGroupsActive : Boolean;
  userGroupsInTenantLevel : Boolean;
  secondaryIdentifierPresence : SecondaryIdentifierPresence;
  dualIdentifierRegistration : DualIdentifierRegistration;
  emailVerificationRequiredForLogin : Boolean;
  mobileVerificationRequiredForLogin : Boolean;
  mobile2FARequiredForLogin : Boolean;
  email2FARequiredForLogin : Boolean;
  userRegisterIsPublic : Boolean;
  userAutoAvatarScript : MScript;
  userGroupAutoAvatarScript : MScript;
}
FieldDescription
primaryLoginIdentifierSpecifies which field is used as the primary login identifier. When set to 'mobile', users register and log in with a phone number instead of email. When set to 'emailOrMobile', both are supported. Defaults to 'email' for backward compatibility.
superAdminIdentifierThe login identifier of the super admin user. When primaryLoginIdentifier is 'email' or 'emailOrMobile', this should be an email address. When it is 'mobile', this should be a mobile number in E.164 format (e.g. +905551234567). If left at the default "admin@admin.com" and primaryLoginIdentifier is 'mobile', Mindbricks automatically replaces it with "+10000000001" during validation. A custom email in a mobile-primary project causes a validation error. This user has full permissions across the project and is not tenant-scoped.
superAdminPasswordThe password of the super admin user. This preset password is used to access the system after initial deployment and should be changed in production environments.
userNameTypeSpecifies whether the user's name will be stored as a single 'fullname' or as separate 'name' and 'surname' fields.
superAdminDataPreset values for the super admin user. Required only for custom properties beyond the standard fields (identifier, name, password, etc.).
userGroupsActiveIndicates whether user group functionality is enabled. When active, a 'userGroup' data object is added to the user service with fixed fields (id, name, description), optionally scoped by tenant.
userGroupsInTenantLevelIf true, user groups are defined per tenant; otherwise, they are defined globally across the SaaS. Applies only when user groups are enabled.
secondaryIdentifierPresenceControls whether the non-primary identifier field (mobile when email is primary, email when mobile is primary) is stored in the user data model. When set to 'none', the field is omitted entirely. When 'optional', the field exists but is not required. When 'required', the field must be provided during registration. Ignored when primaryLoginIdentifier is 'emailOrMobile' (both always exist).
dualIdentifierRegistrationOnly applies when primaryLoginIdentifier is 'emailOrMobile'. Controls whether users must provide both email and mobile during registration ('both'), or just one of them ('atLeastOne').
emailVerificationRequiredForLoginIndicates whether users must verify their email address before they can log in. Related verification flows must be enabled in VerificationServices.
mobileVerificationRequiredForLoginIndicates whether users must verify their mobile number before logging in. This applies only when the mobile field is present in the user data model.
mobile2FARequiredForLoginIndicates whether two-factor authentication via mobile is required during login. This applies only when the mobile field is present in the user data model.
email2FARequiredForLoginIndicates whether two-factor authentication via email is required during login. Related verification flows must be enabled in VerificationServices.
userRegisterIsPublicDetermines if users can self-register. If false, only administrators can create users.
userAutoAvatarScriptAn MScript expression that generates a default avatar for the user. This is used when no avatar is provided in the request.
userGroupAutoAvatarScriptAn MScript expression that generates a default avatar for the user group. This is used when no avatar is provided in the request.

PrimaryLoginIdentifier

Specifies which field is used as the primary login identifier for user accounts.

const PrimaryLoginIdentifier = {
  email: "email",
  mobile: "mobile",
  emailOrMobile: "emailOrMobile",
};
EnumDescription
emailEmail is the primary login identifier. Users must register and log in with an email address. This is the default behavior.
mobileMobile number is the primary login identifier. Users register and log in with a phone number (WhatsApp-style). Email becomes optional.
emailOrMobileBoth email and mobile are supported as login identifiers. Users can register and log in with either an email address or a mobile number.

SecondaryIdentifierPresence

Controls the presence and requirement level of the non-primary identifier field in the user data model.

const SecondaryIdentifierPresence = {
  none: "none",
  optional: "optional",
  required: "required",
};
EnumDescription
noneThe secondary identifier field is not stored in the user data model at all. When email is primary, mobile is omitted. When mobile is primary, email is omitted.
optionalThe secondary identifier field exists in the user data model but is not required during registration. Users may optionally provide it.
requiredThe secondary identifier field exists in the user data model and must be provided during registration.

DualIdentifierRegistration

Controls registration behavior when primaryLoginIdentifier is 'emailOrMobile'. Ignored for other values.

const DualIdentifierRegistration = {
  atLeastOne: "atLeastOne",
  both: "both",
};
EnumDescription
atLeastOneUsers must provide at least one identifier (email or mobile) during registration. They can log in with whichever they provided.
bothUsers must provide both email and mobile during registration. Both fields are required and both can be used for login.

UserNameType

Specifies how user names are represented in the data model.

const UserNameType = {
  asFullname: "asFullname",
  asNamePair: "asNamePair",
};
EnumDescription
asFullnameStores the user's name in a single 'fullname' field.
asNamePairStores the user's name in separate 'name' and 'surname' fields.

LoginDefTenantSettings

MPO Version: 1.3.0

Specifies how tenant-based access control is structured for multi-tenant projects. This includes the tenant object name, registration permissions, and tenant separation logic. When enabled, this enforces strict data and user isolation by tenant.

interface LoginDefTenantSettings = {
  useMultiTenantFeature : Boolean;
  configuration : LoginDefTenantSettingsConfig;
}
FieldDescription
useMultiTenantFeatureEnable this if the project requires multi-tenant architecture. If false, the project will be treated as single-tenant and no tenant-based separation is applied.
configurationThe configuration object for tenant settings. Leave it null if useMultiTenantFeature is false.

LoginDefTenantSettingsConfig

MPO Version: 1.3.0

Configuration details for tenant-based access control, including tenant registration, naming, and avatar script.

interface LoginDefTenantSettingsConfig = {
  tenantRegisterIsPublic : Boolean;
  tenantName : String;
  tenantAutoAvatarScript : MScript;
}
FieldDescription
tenantRegisterIsPublicIf true, any user can create a tenant. If false, only SaaS admins can register tenants. When a user creates a tenant, they are automatically assigned as the tenant owner.
tenantNameDefines the name of the tenant object in the system (e.g., 'client', 'organization', 'workspace'). This name will be used to generate code, database models, and field references.
tenantAutoAvatarScriptAn MScript expression that generates a default avatar for the tenant. This is used when no avatar is provided in the request.