Authentication mechanism details
Authentication overview
FinTrack uses Supabase Auth as its identity provider. The live identity inventory is predominantly phone-based. A restricted corporate-email login route is also implemented for approved administrative use.
Supported sign-in paths
| Path | User input | Validation sequence |
|---|---|---|
| Phone login | Tenant context, registered phone number, and password | Tenant and phone association are validated first; Supabase Auth then verifies the phone identity and password |
| Corporate-email login | Approved corporate email address and password | The application accepts only the approved corporate domain; Supabase Auth then verifies the email identity and password |
The tenant-context value used during phone login is an account-routing and eligibility check; it is not a replacement for the user's password. Password verification remains with the managed identity provider.
Protocol and token model
| Element | Technical behavior | Security property |
|---|---|---|
| Identity assertion | Supabase Auth validates the registered phone or approved corporate-email identity against the submitted password | Authentication is centralized in the managed identity provider rather than implemented in application tables |
| PKCE flow | The browser client uses Proof Key for Code Exchange for supported exchanges | An intercepted authorization response cannot be redeemed without the client-generated verifier |
| Access token | A short-lived signed token is presented to managed APIs and protected operations | Backend services derive the authenticated subject from a verifiable token rather than a browser-supplied user identifier |
| Refresh token | The browser retains refresh capability and rotates the session through the identity provider | Long-lived continuity is separated from individual access-token lifetime; replay and reuse controls remain provider configuration concerns |
| Application profile | A linked profile adds tenant, hierarchy, account-status, and business-scope context | A valid identity without an eligible application profile does not receive an authorised application session |
| Authorization enforcement | Database policies, storage policies, and trusted operations evaluate current server-side state | UI visibility and token claims do not independently authorize protected records or privileged actions |
Authentication state machine
| State | Entry condition | Permitted behavior | Exit condition |
|---|---|---|---|
| Unauthenticated | No usable signed session exists | Public application shell and login processing only | Successful password authentication or continued rejection |
| Identity authenticated | The managed provider has issued a valid session | Resolve the linked application profile; protected business data remains unavailable until eligibility succeeds | Eligible profile, missing profile, inactive profile, or session failure |
| Application eligible | Profile is active and tenant context is valid | Establish user context and request protected data through policy-enforced services | Explicit sign-out, token failure, profile deactivation, or tenant-scope rejection |
| Refreshing | Access token approaches expiry or the application resumes | Suspend assumptions based on stale identity state while the provider refreshes and the profile is rechecked | Rotated session returns to eligible state; failure returns to unauthenticated |
| Rejected | Credentials, context, status, or policy evaluation fails | Return a non-sensitive failure and avoid exposing which validation predicate failed | A new authentication attempt begins |
Session lifecycle
| Stage | Control |
|---|---|
| Session issuance | Supabase Auth issues a signed access-token and refresh-token pair after successful password authentication |
| Browser flow | The client uses Proof Key for Code Exchange for supported authentication exchanges |
| Persistence | The authenticated session is persisted in browser storage so an authorised user can resume the application |
| Refresh | Access tokens are refreshed automatically; the application also checks sessions when it starts and when a suspended browser tab becomes active |
| Expiry handling | Missing, invalid, or expired session state clears the application identity and returns the user to login |
| Account eligibility | Access requires a login-eligible linked application profile; inactive or offboarded users are rejected and signed out locally |
| Sign-out | User sign-out clears the current browser session and authentication-related application state |
Because the refresh token is stored in the browser, cross-site scripting prevention is a material session-security control. A malicious script executing in the application origin acts within the user's session even when the token value is not directly readable.
Identity and authorisation boundary
Authentication establishes who the user is; it does not by itself determine everything the user can access.
- Supabase Auth verifies the password and issues the signed session.
- The application resolves the linked user profile, tenant, account status, and assigned access context.
- Navigation controls limit visible application functions.
- Database grants, row-level security, storage policies, and trusted operation checks remain the authoritative enforcement boundary.
- Selected privileged server operations revalidate the authenticated actor, tenant, role, and requested object before elevated processing. Complete operation coverage is not available.
Password management
- Password values are verified by Supabase Auth and are not stored as plaintext in the application database.
- An authenticated password change requires verification of the current password before the managed identity password is updated.
- Administrative user-management operations execute through trusted server controls rather than exposing privileged identity credentials to the browser.
- A complete self-service recovery workflow is not implemented. Public self-service recovery remains unavailable until an approved support workflow, identity-verification standard, administrative authorization, session revocation step, and audit record are established.
Current security posture
| Control | Current observation |
|---|---|
| Password authentication | Active for registered phone identities and the restricted corporate-email path |
| Signed sessions | Active through managed access and refresh tokens |
| PKCE | Configured in the browser client |
| Automatic refresh | Configured, with additional foreground-session validation |
| Account-status gate | Active for application profiles |
| Multi-factor authentication | Not currently enforced; no enrolled factors were observed in the live read-only snapshot |
| Breached-password screening | Managed security advisor reports that leaked-password protection is disabled |
| CAPTCHA and account-level abuse controls | Not established from the available account evidence |
| Global session revocation | Not established by the normal user sign-out flow, which clears the current browser session |
Required hardening
- Enable breached-password screening and document the approved password policy.
- Introduce phishing-resistant or time-based multi-factor authentication for privileged users, then expand according to risk.
- Apply uniform pre-authentication failure messages, rate limits, progressive delay, and bot protection to login-context validation.
- Define access-token lifetime, refresh-token reuse protection, inactivity timeout, maximum session duration, concurrent-session policy, and administrator-initiated revocation.
- Document and test password recovery, lost-device handling, offboarding, and emergency account suspension.
- Revalidate sensitive operations against current server-side identity and authorisation state rather than relying only on browser-held session claims.
Authentication failure behavior
| Failure | User-visible result | Security handling |
|---|---|---|
| Unknown tenant or identity association | Generic authentication failure | Do not reveal whether tenant, phone, email, or profile exists |
| Incorrect password | Generic authentication failure | Managed provider applies configured rate limits; application avoids credential logging |
| Inactive or offboarded profile | Access is refused and local application identity is cleared | Current profile state overrides a previously valid browser session |
| Expired or invalid access token | Protected request fails and session refresh or reauthentication begins | Backend does not trust stale client state |
| Failed refresh | User returns to login | Clear application context and avoid replaying privileged or non-idempotent operations automatically |
| Missing authorization after successful authentication | The requested route or operation is denied | Authentication success does not bypass tenant, role, ownership, row, or workflow rules |
| Suspicious repeated attempts | Current configuration provides managed rate limits; full account-level abuse controls remain an open action | Introduce challenge, progressive delay, alerting, and incident correlation without enabling account enumeration |
Hardening verification plan
The authentication control is complete only after tests cover correct and incorrect credentials, unknown tenant context, inactive profiles, session expiry, token refresh, token reuse behavior, foreground revalidation, current-session sign-out, administrator revocation, offboarding, concurrent sessions, lost-device handling, password recovery, MFA enrollment and challenge, breached-password rejection, rate limiting, CAPTCHA or bot challenge, and uniform failure messages.
Evidence basis and limitations
The description is based on application behavior, a live read-only identity and factor inventory, current managed-service security advisories, and authoritative Supabase guidance. It does not publish user counts, credentials, token values, internal account identifiers, or implementation details. Account-level password settings, CAPTCHA, rate limits, token lifetime, SMTP/SMS configuration, and administrative access logs require separate provider-account evidence.