SSO & Authentication

The platform supports multiple authentication methods: password-based login, Google OAuth (SSO), 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 server rejects with mfa-required and 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 active: false 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:

In Single-Tenant Mode:

• User provides email, password, and name
• Account is created with active: false -- admin approval is required
• The default app role is assigned
• Admins are notified about the new registration

In SaaS Mode (Multi-Tenant):

• User provides email, password, and name
• Account is created with active: true (auto-activated)
• A solo organization is created for the user automatically
• The user becomes the owner of their organization
• 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

Google OAuth (SSO)

Overview

The platform supports Google OAuth for single sign-on. When configured, a "Sign in with Google" button appears on the login page.

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 "Sign in 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 with the Google profile information
• The email is set from the Google account (marked as verified if Google reports it as verified)
• A profile photo URL is stored from the Google profile
• A Strongly API key is generated
• In SaaS mode: a solo organization is created, and the user is auto-activated
• In single-tenant mode: the user is created with active: false (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 explicitly skips OAuth logins (attemptInfo.type !== 'password')
• Users who log in via Google are not prompted for the platform's MFA codes

Checking Google OAuth Status

The login page calls auth.isGoogleConfigured to determine whether to show the Google button. This method checks if a Google service configuration exists in the database.

MFA Enforcement with SSO

How MFA Enforcement Works

When MFA is enforced platform-wide:

1. The MFA Enforcement Guard component wraps all authenticated routes
2. On each page load, it checks:
   • Are MFA settings enforced? (via mfa.settings publication)
   • Does the current user have MFA enabled? (via mfa.status publication)
3. If MFA is enforced and the user has not set it up:
   • The system calls mfa.checkEnforcement to check 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 enforcedAt 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 client-side tracks user activity and handles inactivity:

1. If the user is idle for 60 minutes, the server-side cleanup removes their session
2. The next time the client tries to communicate with the server, the session is invalid
3. The user is redirected to the login page with the message "You have been logged out due to 60 minutes of inactivity"
4. The wasInactive flag is stored in session storage so the login page can display the message

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
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	Per-email rate limits on MFA verification endpoints
Audit logging	All security events logged and archived to S3
Encryption	API tokens and SSH private keys are encrypted at rest

Important

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