Skip to Main Content

User authentication and sign-up is a foundational feature of any B2B SaaS application. Our primary goal with Baseplate is to support the ability for end users to create customers and log in with minimal friction. Our focus is on supporting third party authentication via federate logins and providing Single Sign-On (SSO) support for enterprise license customers. 

At its core, this feature addresses a user’s need for simplicity and security. A robust authentication system is more than just a login screen: it must handle different user contexts, control who can access which customer, and manage user lifecycle events such as onboarding, offboarding, and role changes. The underlying business problem is that modern organizations have varying standards and restrictions around user customers. Many prefer to manage identities via a federated approach (e.g., Google Workspace, Microsoft Entra, or LinkedIn) to reduce manual steps and to integrate with existing user directories. Others need direct username/password customers for external or temporary staff, or to accommodate smaller clients that do not have advanced identity management solutions. By offering both federated and native sign-up flows, the feature expands the potential user base.

From a user’s perspective, the authentication process should be nearly invisible. Most users expect a familiar interface: a simple login form with an option to sign in via a known provider. For them, a secure and frictionless experience is paramount – they should not have to click through multiple steps or fill out lengthy forms.  For developers looking at existing models, large-scale SaaS products—whether something like Atlassian’s suite (which supports Google, Microsoft, and SSO) or smaller apps that leverage OAuth-based social logins—serve as inspiration for how to simplify the user journey while still meeting enterprise-level requirements.

This feature will be implemented in a way that extensively leverages the Supabase authentication framework. By leveraging existing SDKs and APIs, the application can reliably offload a large portion of the security logic to a trusted platform, while still retaining the flexibility to configure customer-specific settings, role-based policies, and specialized sign-up flows.

For the initial MVP release of the Stock SaaS Application, we will not include native MFA support as part of the standard feature set. Users who require additional security measures beyond basic username/password authentication will be directed toward either federated customer sign-up (e.g., Google Workspace, Microsoft Entra, LinkedIn) or an Enterprise license upgrade that enables MFA through customer-specific SSO configurations. This approach streamlines our development focus on core functionalities while still providing an MFA pathway for users with higher security requirements.

Enterprise SSO Support

For any enterprise customer Single Sign-On (SSO) integration is a core requirement.  This enables customers to manage user provisioning and deprovisioning from one centralized system. Enterprises want to ensure that when a user leaves or changes roles, their access is automatically updated across all integrated applications. 

For enterprise SSO we’ll support the two most common protocols SAML 2.0 and OpenID Connect (OIDC):

Just-In-Time (JIT) Provisioning: The Stock SaaS Application will use the attributes received via SSO (from the Attribute Mapping) to automatically create or update user accounts the first time a user logs in via SSO.

Protocol Choice: Ideally support both noting that SAML 2.0 remains the dominant standard for enterprise B2B SSO.

NOTE: Firebase authentication supports both SAML and OpenIDConnect out of the box so all we should be doing is exposing those services in the application versus building “much”.

The section of the login dialog that provides for e-mail login first shows just an email address input field accompanied by a “Go” button. Upon submission, the system performs a lookup against its user records using the provided email. If the email’s domain is configured for Single Sign-On (SSO), the application immediately initiates the SSO validation process. Otherwise, for registered users, the dialog dynamically expands to include a password field, enabling standard login. For unregistered emails, the system seamlessly transitions into the registration flow, pre-populating the email address field to streamline the signup process.

Role Access and User Stories

System Administrator

System Administrators are the gatekeepers of the platform, entrusted with setting up high-level configurations and ensuring that authentication aligns with organizational and customer security requirements. In this feature, System Administrators can configure, enable or disable certain authentication types globally (e.g., LinkedIn, Google Workspace, Microsoft Entra), manage fallback methods like username/password. They may also handle the advanced aspects of SSO for specific enterprise customers, including approving or rejecting configurations and monitoring authentication logs for suspicious activity. Essentially, their job is to guarantee that each customer and user has the correct access to the appropriate functionalities, no matter which sign-up or login method is used.

Note that none of the above features need a user interface and configuration via Firebase Remote Config (preferred) or via native code configuration updates is the preferred approach. 

Customer Success

Customer Success representatives benefit from the authentication feature by having the ability to step in and assist users who encounter login or sign-up problems. They need access to user customer overviews, including which authentication methods each user has set up and if any federation links are established. This visibility allows them to troubleshoot on behalf of the user—resetting customers, walking them through MFA activation, or helping them transition to a federated login if they initially chose direct username/password. However, Customer Success typically does not manage system-wide configurations; instead, they focus on resolving issues at the customer or user level to maintain seamless customer experiences.

Customer Administrator

customer Administrators hold the keys to their specific customer’s user population and security policies. They need the ability to decide which authentication methods to allow within their customer—perhaps restricting employees to Microsoft Entra sign-in or enabling both Google Workspace and username/password for contractors. More importantly they can configure the customer’s SSO integration for enterprise-level clients, ensuring that provisioning and deprovisioning rules match internal HR systems. By aligning user access to internal policies, customer Administrators maintain security, compliance, and user convenience. This level of autonomy ensures each organization’s unique requirements are met without requiring changes at the system-wide level.

Manager

Managers do not typically handle the system configurations for authentication, but they do need insights into their direct reports’ access. For example, a Manager may request that new team members be invited using the correct authentication method or verify that certain employees have enabled MFA if the company or customer policy demands it. They might view which method each report is using, and they may escalate issues to the customer Administrator or Customer Success if a direct report is having trouble accessing the system. Overall, Managers primarily consume data about user access and occasionally initiate user provisioning requests; they do not actively configure or enforce customer-wide settings.

Standard User

Standard Users are the primary consumers of the authentication feature. They log in daily and manage their personal credentials if not using a federate login provided. Standard Users in an enterprise environment might also rely on a federated login if their company has set up SSO or if they have chosen to link their customer to a Google or Microsoft identity. From a day-to-day standpoint, this feature is largely self-service: they expect reliable logins and straightforward customer recovery procedures.

Pages and Screens

Implementing this feature will involve creating or customizing several pages and screens that guide users and administrators through the authentication process. Each page must be intuitive, secure, and flexible enough to support the varying flows (federated sign-in, native username/password, SSO, etc.). Below is a list of these pages along with their descriptions.

Sign-Up Dialog

The Sign-Up dialog is the first point of contact for new users. Here, users can choose from the available sign-up methods: federated identity providers (LinkedIn, Google Workspace, Microsoft Entra), or the classic username/password approach. The dialog is all about minimizing friction making it as simple for the user as possible to login to the application.  It will show federated sign-up options first and indicate they are the recommended method for sign-up.

If a user opts for username/password, the page will request essential details such as username (often an email) and password.  If the customer’s policies dictate certain restrictions—like enforcing only Google Workspace sign-ups—these rules are enforced in the verification step of the dialog. The system should display relevant guidance messages, helping the user understand why some options are unavailable or how to complete certain security requirements.

The dialog should also handle error states gracefully, presenting concise instructions if the identity provider denies access or if the user’s email is already taken.

The dialog is organized around two basic paths:

Upon completion the user is automatically redirected to / dropped into the application specific Onboarding Wizard.

Login Dialog

The Login dialog is shown when users activate the login link.  It contains options for the supported federated identity providers or a username and password field set for native credentials. For enterprise customers with SSO enabled, the dialog will automatically redirect to the customer’s identity provider if the user is already logged into their corporate network.

Error handling is critical here. Users must see clear messages if their credentials are invalid, or if there’s a misconfiguration with a third-party provider. For instance, if the customer has disabled direct username/password sign-in, the page should inform the user and suggest alternative methods. 

By default we include an active “Remember Me” feature, which makes re-authentication less frequent while balancing security requirements.  When this field is active the cookies user name is pre-populated into the username / password area of the page.

The Login dialog includes two links in the username / password area: one to the registration dialog and another to a forgot password workflow.

SSO Integration Configuration Page

The SSO Integration Configuration Page is only available to System Administrators, Client Success and customer Administrators with active enterprise licenses.  Other users see a “grayed out” (inactive) option here with a tooltip that notes SSO is only available for enterprise license holders.   Here, users can set up and manage SSO connections with their preferred identity providers using protocols like SAML or OAuth 2.0. The page may ask for metadata, certificates, redirect URLs, or other connection details. Upon successful configuration, users from the customer’s directory can be automatically provisioned and deprovisioned in the SaaS application, drastically simplifying user management.

Because this is a critical security function, the page needs robust validation and error handling. For instance, if the customer Administrator uploads the wrong certificate or misconfigures the entity ID for SAML, the system should provide clear debugging information. Additionally, the interface might offer a “Test SSO” button, letting the administrator confirm that everything is working before pushing the configuration live for all customer users.

In many enterprise contexts, the ability to control user lifecycles is essential. This page should display whether automatic deprovisioning is enabled—so that if a user is removed from the corporate directory, they’re also removed from or locked out of the SaaS application. customer Administrators might also see a summary of which users have logged in via SSO. The overarching goal is to provide a singular control center for all enterprise-level authentication needs, simplifying compliance and security tasks for large organizations.

User Authentication Settings

As part of the “Settings” section of the application, this page provides authentication details for all users in a specific customer.   Customer Administrators, System Administrators, and Customer Success roles would have the ability to view it.  It will list each user’s chosen login method and whether they’ve linked any federated customers. This bird’s-eye view helps administrators identify at a glance if certain users are missing required authentication steps.

From here, admins can reset user passwords, revoke session tokens, or invite a user to switch to a federated login. customer Administrators can also track which roles are assigned to which user, ensuring that the principle of least privilege is followed.

The page should also include some basic authentication analytics: 

Company Email Detection 

Company Email Detection is designed to ensure that each end user of an application built on the Stock Application framework has an authenticated corporate or organizational email on file. Today platforms struggle with validating that a user signing up actually belongs to (or has the right to represent) a specific organization.   We want to allow personal emails (e.g., Gmail, Hotmail, Yahoo) for initial sign-up to reduce friction.   These personal e-mail addresses, however, fail to verify whether the user truly belongs to a particular paying customer or licensed organization. This shortcoming could lead to ambiguous or incorrect data partitioning, unauthorized feature access, and confusion when the system attempts to auto-provision roles or manage licensing.  By integrating a detection function for company e-mail at the beginning of any key workflows the application can prompt and confirm corporate email addresses at the correct time—i.e., when a user truly needs to be placed inside the correct “company context” in order to proceed.

From the user’s point of view, the core business problem solved is frictionless but accurate verification of their organizational identity.  While an application can allow initial sign-up from any valid e-mail account as soon as the system needs to apply role-based restrictions, share sensitive or licensed data, or link an account to a paying entity, the user must confirm they belong to a legitimate corporate domain. “Company Email Detection” handles this by detecting whether a user’s primary login email is from a personal email provider or from a recognized corporate domain. If it’s from a personal provider—or if it’s unknown—then the system politely prompts the user to provide a valid, controlled address.

The interface to do this is an intelligent dialog that appears at the start of any workflow that requires the user be placed in a correct company context.  It informs the user why a corporate email is needed to access the given feature, instructs them to enter that address, and initiates a simple verification process. Verification is accomplished by sending an automated link and code to the provided corporate address. Once the user either clicks on the link or copies the code back into the dialog, the system confirms that the user truly has control of that company email. From there: 

Technically, the feature checks the user’s email domain against a the official list of personal email providers.  If the user’s domain is recognized as a standard free email provider, or the system is otherwise configured to distrust that domain, the system triggers the corporate email dialog. If a corporate address is recognized (e.g., the domain doesn’t appear in the personal domain list and is presumably not free), the system sets that as the user’s primary “work” email , places the user in the correct Customer and no further action is required.  

System and Customer Administrators can override the default behavior and manually set a user’s primary company e-mail to be a personal e-mail address.

This approach is similar to other enterprise collaboration applications that restrict personal addresses for enterprise features Slack and Microsoft Teams being simple examples where a domain-based approach to provisioning is standard. Another example is some specialized workflow applications where open sign-up is allowed, but once you attempt to join a corporate project or team, you are forced to prove you belong to that company’s domain. This feature merges these concepts into a single, user-friendly dialog that fits elegantly into the Stock Application’s standard authentication flows.

While the vast majority of use of this feature will be self service this feature provides some administrative fallback procedures. In rare cases, a user might be forced to use a personal email address for legitimate reasons (e.g., they are a contractor or external collaborator). If so, the system instructs them to contact their Customer Administrator to manually add them to their organization or contact support and request explicit association with a specific customer. This approach ensures that suspicious or unrecognized domains aren’t automatically granted corporate-level access. 

The “Company Email Detection” should leverage all the standard Firebase Authentication models to ensure the solution remains consistent with the Stock Application’s security posture and multi-customer architecture. Administrators can rely on domain checks and optional overrides, while standard users benefit from a clean, minimal-interruption flow. Ultimately, the feature strikes the right balance between frictionless sign-up (allowing personal addresses) and robust identity verification (needing a corporate address when it matters).

Multiple E-mail Support

Supporting individuals with multiple e-mail addresses linked to a single account. This functionality addresses a common requirement among users who may have both personal and corporate e-mail addresses.

In the typical scenario, a user initially signs up using their personal e-mail address, which grants them limited access to the system. When the user needs to access specific customer information or functionalities that require higher privileges, they are prompted to provide their corporate e-mail address. This dual e-mail support not only streamlines the access process but also ensures that users can seamlessly transition between personal and professional contexts within the system.

Role Access and User Stories

System Administrator

System Administrators oversee the entire application and all customer data. While they may not manually verify every user’s email, they are responsible for defining global policies such as which domains are in the “personal email list,” customizing the threshold for domain detection, and deciding how strict or lenient the corporate email verification process should be. They also manage fallback requests from users who cannot produce a recognized corporate email.

User Stories

  1. Configure Personal Domain List
    As a System Administrator, I want to maintain the master list of known personal email domains (e.g., gmail.com, Yahoo | Mail, Weather, Search, Politics, News, Finance, Sports & Videos ), so that the system automatically detects these addresses and prompts users for a corporate email.  This data can be stored in a static file that is editable on an infrequent basis
  2. Set Global Dialog Content
    As a System Administrator, I want to configure the dialog’s text and disclaimers centrally, so that every user sees a consistent explanation of why a corporate email is required.  This configuration information should be provided via Firebase Remote Config.
  3. Monitor Verification Attempts
    As a System Administrator, I want to view logs of successful and failed corporate email verifications, so I can audit how often domain checks are triggered and which addresses are repeatedly failing.
  4. Disable Feature for Test Environments
    As a System Administrator, I want to disable the company email detection prompts on dev or staging servers, so that testers aren’t forced to go through verification steps every time they run a scenario.

Customer Success

The Customer Success team (sometimes called Support) interacts directly with end users who are confused by or having trouble with the corporate email prompt. They may need to manually verify a user’s corporate domain, handle exceptions (e.g., a user genuinely cannot provide a corporate domain), or advise on how to proceed.

User Stories

  1. Help User With Email Verification
    As a Customer Success agent, I want to re-send verification links to a user who cannot find the original email, ensuring they can complete the process without resetting their account.
  2. Investigate Fallback Requests
    As a Customer Success agent, I want to review fallback requests from users who claim they have no corporate email, so that I can escalate them to the correct team or associate them with a tenant in an exceptional manner.
  3. Manual Company Email Setup – As a Customer Success agent, I want to be able to manually set a personal e-mail as a valid company e-mail for a given user and provide them access to a specific Customer.
  4. View Verification History
    As a Customer Success agent, I want to see the verification status and timestamps for each user’s corporate email, so I can troubleshoot why they might not have been placed into the correct tenant.
  5. Provide Step-by-Step Assistance
    As a Customer Success agent, I want to impersonate a user and walk through the “Company Email Detection Dialog” to see exactly what the user experiences and provide accurate, targeted help.

Customer Administrator

Customer Administrators manage user access and domain logic within a specific organization or customer account. This means they may want to refine or override the domain detection policy for their own organization, especially if their company uses multiple domains or subdomains. They also might do “bulk invites” to ensure new employees automatically skip personal email friction by using their recognized corporate domains.

  1. Add and Edit E-mail Domains
    As a Tenant Administrator, I want to specify additional recognized corporate domains for my own company, ensuring new employees on, for example, a newly acquired subdomain are treated as corporate from day one.
  2. Invite New Users
    As a Tenant Administrator, I want to invite new users by sending them a direct link that pre-populates their known corporate domain, so that they do not see personal email detection prompts unnecessarily.
  3. Manually Approve an Edge Case
    As a Tenant Administrator, I want to manually confirm an external contractor with a personal email, associating them with my Customer organization for a limited time, so they can access data despite not having my corporate domain.

Manager and Standard User

Managers and Standard Users are the primary participants in the corporate email detection workflow. They will either be unaffected (if they initially sign up with a recognized corporate domain), or they will see a prompt to provide and verify a corporate address at the appropriate time. They need a clear, unobtrusive user experience.

User Stories

  1. Prompt on First Need
    As a Standard User, if I logged in with a personal address, I want to see a dialog prior to access a feature requiring a corporate address, telling me why I need a corporate email, so I can quickly enter and verify that address.
  2. Receive Verification Link
    As a Standard User, I want to receive a code or link via my corporate email, ensuring I can simply click or copy-paste the code to prove ownership.
  3. Resend Verification
    As a Standard User who never received the verification email, I want to request that the system resend it, so I am not locked out of corporate features due to missed or spam-filtered mail.
  4. Contact Support
    As a Standard User with no corporate email, I want an in-dialog option to reach out to the support team for a manual placement, ensuring I can still proceed if truly needed.
  5. View Verified Status
    As a Standard User, I want to quickly check that my corporate email is confirmed, so I know I have full access to my organization’s data and licensed features.


Pages and Screens

Email Detection Prompt Dialog – Entry Screen

The Email Detection Prompt is a modal-style dialog that appears if a user’s primary login address is flagged as personal or unknown. It explains that a valid corporate address is required to access or unlock certain data. The text is succinct but emphasizes the rationale—“We need a verified company email to confirm your affiliation and provide you with licensed features.”

The dialog shows a field to enter a valid company e-mail address.   When the user submits the submission is checked for formatting (that it is a properly formatted e-mail) and that the domain is not on the list of personal e-mails.   If either fails a relevant error message is provided.  If the entry is validated a verification email is sent. 

This dialog must be intuitive and minimal. Key design elements include a short but clear explanation, a single text field for the new address, and a “Send Verification” button. Error states (e.g., invalid format) appear inline, and success states highlight that a verification email was just sent.

Email Detection Prompt Dialog – Verification Screen

After the user activates the Send Verification button the Verification Screen is shown in the dialog.   This simple screen shows the text: “Check your inbox at, find the code we sent, and input it below.” If the code matches, the system records this as the user’s “primary corporate email” and gives them access to the blocked feature.   If not, an error message suggests re-checking the email or requesting another code.

Email Detection Prompt Dialog – Support Request Screen

For user’s who cannot produce a valid corporate domain email address a Request Support button is provided in the the main detection dialog. When clicked, it reveals instructions: “If you do not have a corporate email but need access to a specific organization let us know what the situation is and what organization you need access to and we’ll work on getting you access.”  

Submitting this request triggers an internal ticket in the Customer Success queue or notifies the Customer Administrator. The user sees a message like: “We’ve received your request. Our team will contact you about next steps.” Meanwhile, their ability to proceed is blocked for the time being.  

The UI emphasizes clarity, telling users why personal domains are discouraged and how to proceed. The system automatically logs the user’s personal domain, name, and relevant session details so that Customer Success can expedite verification.

Administrator E-mail Domains Page

System Administrators and Customer Administrators are provided a E-mail Domains page where they can add, edit and remove recognized corporate e-mail domains that will automatically grant users access to their Customer setup.   The page also shows a table of user-level overrides—cases where a user with a personal domain was manually accepted or added to the Customer. 

Data Model

Below is an example PostgreSQL data model that supports the Company Email Detection feature. This example would build on the base user authentication support provided via Firebase Authentication.   Note that certain columns—like primary keys, foreign keys, or timestamps—are omitted for brevity, or shown with typical naming conventions.

–Table that stores the list of valid e-mail domains for a customer

CREATE TABLE customer_email_domains (

    id SERIAL PRIMARY KEY,

    domain_name VARCHAR(255) NOT NULL,   — e.g. ‘agency_name.com’, ‘Form a Corporation or LLC In California | MyCorporation ‘

    last_updated TIMESTAMP DEFAULT NOW()

);

— Extension to user table to store primary_corporate_email and verification state, note that if on initial creation of the user we have a valid corporate e-mail address (not a personal one) they are immediately set to verified

TABLE users (

    email VARCHAR(255) NOT NULL,          — user’s login email

    primary_corporate_email VARCHAR(255), — verified corporate email, if any

    corporate_email_verified BOOLEAN DEFAULT FALSE,

    corporate_email_verified_at TIMESTAMP DEFAULT NOW(),

    corporate_email_created_at TIMESTAMP DEFAULT NOW(),

    corporate_email_updated_at TIMESTAMP DEFAULT NOW()

);

— Table to store verification attempts (codes, timestamps, etc.)

CREATE TABLE email_verification (

    id SERIAL PRIMARY KEY,

    user_id INT NOT NULL REFERENCES users(id),

    verification_email VARCHAR(255) NOT NULL,   — the address being verified

    verification_code VARCHAR(50) NOT NULL,     — six digit verification code randomly generated

    verified BOOLEAN DEFAULT FALSE,

    created_at TIMESTAMP DEFAULT NOW(),

    verified_at TIMESTAMP

);

— Table for fallback requests or manual overrides

CREATE TABLE email_fallback_requests (

    id SERIAL PRIMARY KEY,

    user_id INT NOT NULL REFERENCES users(id),

    personal_email VARCHAR(255) NOT NULL,  — user’s personal email

    reason TEXT NOT NULL,                  — user’s justification

    status VARCHAR(50) DEFAULT ‘pending’,  — e.g. ‘pending’, ‘approved’, ‘denied’

    created_at TIMESTAMP DEFAULT NOW(),

    processed_by INT REFERENCES users(id), — ID of admin or success agent who processed

    processed_at TIMESTAMP

);

Notes on the Data Model

  1. users: The user’s single “email” might be the login email, while primary_corporate_email is the confirmed work address. Once verified, corporate_email_verified is set to TRUE. If the user’s email is recognized as corporate from the start, it can auto-populate primary_corporate_email at account creation.  Also not that a user might move between Customers.  In this case both the users customer_id would change and they’d have to revalidate a corporate e-mail address.
  2. email_verification: Each attempt to verify a corporate address for a user gets a row here. verification_email stores the address under verification; verification_code holds the link or code. verified_at populates once the user completes the process.

email_fallback_requests: For users who must remain on a personal domain or cannot produce a corporate address, we track requests here. The “status” helps Customer Success or an admin see if it’s pending approval or was denied.
hat a user’s registered account does not have a primary company e-mail set. 

Get in touch
Company Resources
Compliance
Copyright
  • © 2025 One to One Hundred. All Rights Reserved.
  • Site by Arcbound.