Frontegg Backend

Andi Lamprecht ·2026-05-11· 4 min read· Accepted

FrontEgg Backend and SSO Configuration

Context and Problem Statement

FrontEgg has a number of decisions that needed to be made as it pertains to the backend configuration. The following items are being discussed in this ADR and the reasoning behind their decisions.

1. Account Configuration for Portal
2. Backoffice Accounts and User Management (per environment)
3. Authentication Settings (per environment)
4. Security Settings (per environment)
5. Emails
6. Domains (per environment)

Portal

Security

1. Session Management

1. MFA

• The MFA settings aren’t required as the authentication will be done through Okta.

1. Domain Restrictions

• Portal access has been restricted down to only droneup.com email accounts.

1. SSO

• SSO for the portal is connected to the DroneUp Okta environment.

Backoffice

Accounts - Accounts are the tenant level configuration of FrontEgg. Users are assigned to Accounts and SSO / Admin is per Account.

Development, Staging, & QA

• The Tenants here should be DroneUp and EndUser-Test (name TBD)

1. DroneUp - Users will be SSO to Okta using groups based on the entitlements assigned to the applications.
2. EndUser-Test - Users managed locally to emulate the public end user; can be used for automated testing.

Production

• The Tenants (Accounts) here are actual clients of DroneUp and end users
• Clients are end user customers of DroneUp (i.e. Walmart) who may or may not have users that interact with various applications. The users and m2m authentication falls under this term.

1. DroneUp - Users will be SSO to Okta using groups based on the entitlements assigned to the applications.
2. - Access to admin portal; can manage their own users; allows for enterprise SSO; MFA required if not enterprise SSO
3. Public - Users who sign up with our applications that aren’t part of a client. i.e. DroneUp Deliveries App; MFA required

Authentication

1. Password - Dev / Staging / QA

1. Password - Prod

1. Social Logins - Dev / Staging / QA

• Google - Enabled
• Facebook - Enabled
• Apple - Enabled

1. Social Logins - Prod

• Google - Enabled
• Facebook - Enabled
• Apple - Enabled

Security

1. MFA - Dev / Staging / QA

• Not forced to allow for automated testing

1. MFA - Prod

1. Session Management All Environments

1. Security Rules Dev / Staging / QA / Prod

• Challenge Action : The end user will be prompted for action in the login portal.

Emails

Dev / Staging / QA

• The emails do not need to be activated
• Emails can come from FrontEgg

Production

• All emails need to be enabled.
• Emails need to be sent from the DroneUp domain (support from FrontEgg required)

Domains

• Due to restrictions placed on DroneUp by the vendor the lower environments will not have customized logon domains.
• The customized domains provides the end user with a uniform experience with DroneUp. It also prevents 3rd party cookie issues from arising with modern browsers.

Dev / Staging / QA

• logon domain will be: dev.auth.droneup.com

Production

• logon domain will be: auth.droneup.com

Cited by queries

• DroneUp roles and permissions: as-is across Uncrew, Hubops, UTM, Boundary Creator, Frontegg, Okta, and Lumos — 2026-05-01
• Multi-authority approval, telemetry sharing, and authority/org IAM coverage — 2026-04-28