Authentication Security

whoot. provides multiple layers of authentication security — from configurable MFA policies to SAML SSO integration and real-time session validation — ensuring only authorised users can access your workspace.

Authentication Methods

whoot. supports multiple authentication methods to match your organisation's security requirements:

• Email and password — Standard credential-based authentication with email verification
• SAML 2.0 SSO — Enterprise single sign-on with Okta, Azure AD (Entra ID), Google Workspace, OneLogin, or any SAML 2.0-compliant identity provider
• Multi-factor authentication (MFA) — Time-based one-time passwords (TOTP) as a second authentication factor

Multi-Factor Authentication

MFA adds a critical second layer of protection beyond passwords. whoot. uses TOTP (Time-based One-Time Passwords), compatible with authenticator apps including:

• Google Authenticator
• Authy
• 1Password
• Microsoft Authenticator
• Any TOTP-compatible authenticator app

MFA Enforcement Policies

Administrators can configure MFA policies per tenant with three modes:

MFA policy changes are recorded in the audit log with full context (who changed it, when, and from which policy to which).

Administrator MFA Management

Administrators with the appropriate permissions can manage MFA for other users:

• View which users have MFA enabled
• Disable MFA for a user (e.g. if they lose access to their authenticator app) — this action is logged in the audit trail
• Administrators cannot disable their own MFA through the admin panel — they must use their personal security settings, ensuring no admin can accidentally bypass their own MFA

SSO Security Model

When SAML SSO is configured, authentication is delegated to your identity provider (IdP). This provides several security benefits:

• Centralised credential management — Passwords are managed by your IdP, not by whoot. If a user's corporate credentials are revoked, they lose access to whoot. automatically
• Domain verification — Before SSO can be enabled, you must verify ownership of your email domain by adding a DNS TXT record. This prevents unauthorised SSO configurations
• Enforcement modes — SSO can be optional (users choose to use it) or required (all users with the verified domain must use SSO). When required, email/password login is disabled for those users
• Built-in testing — whoot. includes a Test Connection tool that verifies the SAML integration works before you enforce it, preventing lockouts

See SSO Configuration for step-by-step setup instructions.

Session Management

whoot. implements robust session management to protect against session-based attacks:

• Session expiry — Sessions expire after a configured inactivity period. Users must re-authenticate to continue
• Real-time session validation — The client periodically validates the session with the server (every 30 seconds). If the session is no longer valid — due to expiry, admin revocation, or membership removal — the user is immediately signed out
• Forced logout on revocation — When an admin removes a user from a workspace or revokes their role, the user's active sessions are terminated. They are disconnected from all voice channels and redirected to the login page with a clear explanation
• Cross-tab awareness — Auth state changes (sign-out, session expiry) are detected across all browser tabs

Voice Session Security

Voice connections have additional security controls beyond standard web sessions:

• Clean shutdown on sign-out — When a user signs out, all voice sessions (WebRTC peer connections) are terminated, all audio channels are hung up, and all in-memory credentials are purged
• Clean shutdown on page close — When the browser tab is closed or the page is refreshed, voice sessions are terminated and credentials are cleared using the beforeunload and pagehide events
• Automatic reconnection with re-authentication — If a voice connection drops, the client re-authenticates before reconnecting, ensuring stale or revoked credentials are not reused

Password Security

For users who authenticate with email and password:

• Password reset — Administrators can trigger password reset emails for users in their workspace. This action is logged in the audit trail
• Same-browser requirement — For added security, password reset links must be opened in the same browser where the reset was initiated
• Email verification — New accounts require email verification before they can access any workspace

Authentication Audit Trail

All authentication events are recorded in the immutable audit log:

• User login and logout events
• MFA enrollment and verification
• MFA policy changes
• SSO configuration changes
• Password reset requests
• Failed authentication attempts
• Session expirations and forced logouts
• Access request approvals and denials

Each audit entry includes the actor, action, timestamp, IP address, and full contextual detail. See Security & Compliance for more on audit logging.

Next Steps

• SSO Configuration — Set up SAML SSO step by step
• Security Architecture — Encryption and transport security
• Data Privacy & Isolation — Tenant isolation and GDPR controls
• User Roles & Permissions — RBAC configuration