Authentication & Access Control

Cothon's authentication is built on Supabase Auth. This page describes the sign-in methods, multi-factor authentication, enterprise single sign-on, session behaviour, organization roles, and API tokens as they actually work in the product.

Sign-in methods

Email and password

Create an account with your email address and a password of at least 12 characters. Passwords are stored using industry-standard one-way hashing by Supabase Auth — never in plaintext, and not retrievable by anyone, including Cothon staff.

• Changing your password (Settings → Security) requires re-verifying your current password first.
• Forgot your password? Use the reset link on the login screen; a single-use reset email is sent to your registered address.

Sign in with Google or Microsoft

You can sign in with a Google or Microsoft account via OAuth. Cothon receives only your email address and basic profile information — never your password, emails, or files.

Two-factor authentication (TOTP)

Cothon supports authenticator-app (TOTP) two-factor authentication:

1. Go to Settings → Security → Two-factor authentication and click Enable.
2. Scan the QR code with your authenticator app (1Password, Authy, Google Authenticator, etc.) or enter the setup key manually.
3. Confirm with a current 6-digit code. From then on, every new session must complete an MFA challenge.

Protecting against lockout — Supabase TOTP does not generate one-time recovery codes, so:

• Enroll more than one device (a second factor such as your password manager); any enrolled factor satisfies the challenge
• Prefer authenticator apps with encrypted cloud backup
• Store the manual-entry secret in your password manager

If you lose access to all enrolled factors, account recovery requires identity verification with support and can take several business days.

Organization-wide MFA enforcement

Organization owners and admins can require MFA for all members, with a configurable grace period so existing members have time to enroll before being locked out. Admins can see per-member enrollment compliance. Policy changes are captured in the audit log.

Enterprise single sign-on (SAML)

Organizations on an enterprise plan can federate sign-in to their identity provider (Okta, Microsoft Entra ID, Google Workspace, and other SAML 2.0 IdPs):

• Domain verification with admin approval — your organization's admins submit your email domain from the security settings; Cothon's operations team verifies ownership and approves the mapping before SSO activates. Self-serve domain claims are not accepted, which prevents impersonation.
• Just-in-time provisioning — users are created in Cothon on their first SSO sign-in. Organization membership is managed in the application.
• No SCIM — SCIM provisioning and group-to-role sync are not currently supported.

SSO domain requests, approvals, rejections, and removals are all recorded in the audit log.

Sessions

Cothon uses Supabase Auth's standard JWT session model:

• On sign-in you receive an access token (JWT, valid for 1 hour) and a refresh token. The access token accompanies every API request; when it expires, the client refreshes it automatically in the background — you stay signed in without interruption.
• Tokens are kept in your browser's local storage by the Supabase client library. Sign out on shared computers — closing the tab does not end the session.
• Changing your password or signing out invalidates your session. If you suspect compromise, change your password immediately and contact support.

Organization roles

Every organization member has one of three roles:

Roles are enforced both in the API and at the database layer through row-level security, and role changes are captured in the audit log. A user can belong to several organizations with a different role in each.

API tokens

For programmatic access, create API tokens instead of using your login credentials:

• Tokens use the cothon_live_ prefix (detectable by secret-scanning tools) and are shown once at creation — Cothon stores only a hash
• Each token is scoped to one organization with a role of viewer, member, or admin
• Default expiry is 90 days, with a maximum of 365 days
• Creating a token requires an MFA-verified session
• Revoke a token at any time; revocation is immediate

At runtime, a token is exchanged for a short-lived credential and all requests run under the same row-level security as an interactive user. See API Security for usage details.

Audit trail

Authentication events — sign-ins, password changes, MFA enrollment and challenges, SSO lifecycle, API token creation and revocation, and role changes — are captured in the organization's append-only audit log, viewable by owners and admins.

Best practices

• Enable 2FA immediately, and enroll a second factor as backup
• Use a password manager with strong unique passwords (12-character minimum; 16+ recommended)
• Apply least privilege: most teammates should be members; keep owner to one or two people
• Remove departed employees promptly — or use SSO so deprovisioning in your IdP ends access automatically

Related pages

• API Security — tokens, JWT validation, and rate limits
• Security & Privacy Overview — the full security architecture
• Data Privacy — PIPEDA compliance and data handling