SSO & Authentication

The platform supports multiple authentication methods: password-based login, SAML single sign-on (including Active Directory), Google OAuth, and multi-factor authentication enforcement.

Authentication Methods

Password-Based Login

Standard email and password authentication:

1. User enters email and password on the login page
2. Server validates credentials securely
3. If the user has MFA enabled, the client shows the MFA verification modal
4. After MFA verification (if required), login succeeds
5. The "Remember Me" option saves the email in local storage for convenience

Account Validation on Login:

• In single-tenant mode, users with inactive accounts receive "Your account is pending approval by an administrator"
• Archived users receive "Your account has been archived. Please contact an administrator."
• Locked accounts receive a message with the remaining lockout time
• In SaaS mode, users are auto-activated and skip the approval check

Self-Registration

Users can register new accounts through the registration page. Every new registration also creates a solo organization owned by the user.

In Single-Tenant Mode:

• User provides email, password, and name
• The account is created inactive -- admin approval is required before login
• The default app role is assigned
• Admins are notified about the new registration

In SaaS Mode:

• User provides email, password, and name
• The account is created active (auto-activated)
• The default app role is assigned

Password Requirements for Registration:

• Minimum 8 characters
• At least one uppercase letter, one lowercase letter, one number, and one special character
• Cannot be on the common passwords blocklist

SAML SSO (Active Directory)

Overview

The platform supports SAML 2.0 single sign-on with your identity provider, including Active Directory. When SAML SSO is configured and enabled, the login page shows an SSO button (default label: Sign in with Active Directory -- the label is customizable).

Clicking the button sends the user to /auth/saml, which redirects to your identity provider. After the IdP authenticates the user, it posts the assertion back to the platform's callback URL and the user is signed in.

Hiding Password Login

SAML configuration includes a hide password login option. When enabled, the login page hides the email/password form entirely and shows only the SSO button, with the note "Your organization uses Single Sign-On for authentication." When disabled, the SSO button appears alongside the password form.

Configuring SAML

SAML is configured by an admin at Admin > Security Settings, on the Single Sign-On (SSO) tab:

Setting	Description
IdP Entity ID	Your identity provider's entity identifier
IdP SSO URL	The IdP's sign-on URL the login button redirects to
IdP Certificate	The IdP's signing certificate
Attribute mapping	Which SAML attributes map to email, first name, last name, and display name
Auto-create users	Create platform accounts automatically on first SSO login
Default role	The platform role assigned to auto-created users
Require approval	Whether auto-created users need admin approval
Button label	The text on the login page's SSO button
Hide password login	Show only the SSO button on the login page

A Test Connection action verifies the configuration, and the platform exposes its service-provider metadata XML at /auth/saml/metadata for import into your IdP.

Google OAuth

Overview

The platform supports Google OAuth for single sign-on. When configured, a Continue with Google button appears on the login page (the registration page shows Sign up with Google).

Configuration

Google OAuth requires two environment variables or settings:

Setting	Environment Variable	Settings Path
Client ID	GOOGLE_CLIENT_ID	private.google.clientId
Client Secret	GOOGLE_CLIENT_SECRET	private.google.clientSecret

If neither is set, Google SSO is disabled and the button does not appear on the login page.

How to Enable Google OAuth

Step 1: Create Google OAuth Credentials

1. Go to the Google Cloud Console
2. Create or select a project
3. Navigate to APIs & Services > Credentials
4. Click Create Credentials > OAuth client ID
5. Select Web application as the application type
6. Add your platform domain to Authorized JavaScript origins (e.g., https://your-domain.strongly.ai)
7. Add the OAuth callback URL to Authorized redirect URIs: https://your-domain.strongly.ai/_oauth/google
8. Copy the Client ID and Client Secret

Step 2: Configure the Platform

Set the environment variables:

GOOGLE_CLIENT_ID=your-client-id.apps.googleusercontent.com
GOOGLE_CLIENT_SECRET=your-client-secret

Or add to settings.json:

{
  "private": {
    "google": {
      "clientId": "your-client-id.apps.googleusercontent.com",
      "clientSecret": "your-client-secret"
    }
  }
}

Step 3: Restart the Server

The Google OAuth configuration is loaded on server startup. The login page automatically detects whether Google OAuth is configured and shows or hides the button accordingly.

Google OAuth Login Flow

1. User clicks Continue with Google on the login page
2. A popup window opens with Google's authentication page
3. User selects their Google account and grants permission
4. Google returns the user's profile information (name, email, picture, verified status)
5. The platform handles the user:

For new Google users:

• A new account is created from the Google profile information (name, email, profile photo)
• In SaaS mode the user is auto-activated; in single-tenant mode the account is created inactive, pending admin approval
• The default app role is assigned
• Admins are notified about the new user

For existing users with the same email:

• The Google account is linked to the existing user account

Google OAuth and MFA

Google OAuth logins skip the platform's MFA verification:

• Google has its own 2-Step Verification system
• The MFA validation hook skips non-password logins
• Users who log in via Google are not prompted for the platform's MFA codes

Multi-Factor Authentication

Three MFA methods are supported:

• Authenticator app (TOTP) -- 6-digit codes from an authenticator app
• Email codes -- 6-digit codes sent to the user's email
• Backup codes -- one-time recovery codes generated at setup

MFA Enforcement with SSO

How MFA Enforcement Works

When MFA is enforced platform-wide:

1. The MFA enforcement guard wraps all authenticated routes
2. On each page load, it checks whether MFA is enforced and whether the current user has MFA enabled
3. If MFA is enforced and the user has not set it up:
   • The system checks the grace period
   • If the grace period has expired, the user is redirected to the MFA setup page
   • If days remain in the grace period, the user can continue but sees a reminder

Grace Period

When an admin enables MFA enforcement:

• The enforcement timestamp is recorded
• The grace period countdown begins from this timestamp (not from the user's account creation date)
• Default grace period is 7 days
• During the grace period, users can log in normally but are encouraged to set up MFA
• After the grace period expires, users are redirected to MFA setup on every page load

Allowed Pages During Enforcement

Even when MFA enforcement redirects are active, these pages remain accessible:

• /profile/mfa -- the MFA setup page itself
• /auth/logout -- so users can log out

Session Security

Login Token Management

The platform uses a secure token-based session system for session persistence:

• Each successful login generates a secure login token
• Tokens are hashed before comparison for security
• The session management system tracks active sessions alongside login tokens
• When a session is revoked, the corresponding login token is invalidated

Inactivity Logout

The platform logs users out after 60 minutes of inactivity:

1. After 55 idle minutes the client shows a "Session Expiring" warning with Continue Working and Log Out Now options
2. At 60 idle minutes the session is removed on the server
3. The user is returned to the login page with the message "You have been logged out due to 60 minutes of inactivity."

Remember Me

The login page offers a "Remember Me" checkbox:

• When enabled, the user's email is saved in localStorage
• On the next visit, the email field is pre-filled
• Only the email is remembered, never the password

Security Features Summary

Feature	Implementation
Password authentication	Secure password hashing
SAML SSO	SAML 2.0 with Active Directory and other IdPs
Google OAuth	Google OAuth with popup login
Multi-factor authentication	TOTP + email codes + backup codes
Account locking	5 failed attempts in 15 minutes triggers 30-minute lock
Session management	Max 5 concurrent sessions, 60-minute idle timeout
Password policy	8+ chars, mixed case, number, special char, history of 5
Password expiration	90-day expiration with UI-prompted password change
Security headers	CSP, HSTS, X-Frame-Options, X-Content-Type-Options
Rate limiting	Rate limits on MFA verification
Audit logging	Security events recorded in audit logs
Encryption	Sensitive credentials encrypted at rest

Important

Always keep at least one admin account with password-based login as a fallback in case your identity provider experiences issues. Store the credentials securely in a password manager.