Authentication Repository
Component Detail
Description
Data layer repository providing a stable interface for authentication persistence operations. Manages local session caching via secure storage and delegates remote operations to the Supabase Auth client.
auth-repository
Summaries
The Authentication Repository protects user trust and reduces churn by ensuring login sessions persist reliably across app restarts without requiring users to re-authenticate. This directly improves retention metrics and reduces support tickets related to unexpected logouts. By caching credentials locally in secure storage, the component eliminates unnecessary network calls, lowering infrastructure costs and improving the perceived speed of the application. As a shared component reused across all authenticated features, it centralises a critical security boundary, reducing the risk of data breaches and ensuring compliance with best-practice credential handling.
Its stable interface also allows the underlying auth provider to be swapped in future with zero impact on the rest of the product.
The Authentication Repository is a low-complexity data-layer component that should be deliverable within one to two sprint days by a single mobile developer. Its primary dependency is the Supabase Auth Client, which must be initialised and tested first, making sequencing straightforward. Testing requirements include unit tests for each of the five public interface methods, secure storage integration tests, and session validity edge-case coverage (expired tokens, null sessions). The component is shared across features, so any breaking interface change carries broad project impact and requires coordinated regression testing.
Deployment risk is low given its local-only caching responsibility, but security review of the secure storage implementation should be scheduled before the first production release.
The Authentication Repository sits at the boundary between the domain layer and infrastructure, implementing the Repository pattern to abstract all session persistence concerns. It wraps platform secure storage (e.g., flutter_secure_storage) for token caching and delegates remote auth operations to the injected SupabaseAuthClient. The five public methods map cleanly to domain use cases: saveSession/clearSession handle login and logout lifecycle, loadSession rehydrates state on cold start, isSessionValid performs a synchronous local token expiry check without a network round-trip, and getUserProfile fetches profile data via Supabase. DTOs returned by Supabase are mapped to internal UserProfile domain models within this layer, keeping domain models decoupled from SDK types.
As a shared singleton injected via a DI container, care must be taken to avoid race conditions on concurrent saveSession/clearSession calls.
Responsibilities
- Cache and retrieve session tokens using secure local storage
- Persist and clear user session on login and logout
- Expose session validity check without network round-trip
- Bridge domain auth models with Supabase response DTOs
Interfaces
saveSession(Session session) Future<void>
loadSession() Future<Session?>
clearSession() Future<void>
isSessionValid() bool
getUserProfile(String userId) Future<UserProfile>
Relationships
Related Data Entities (2)
Data entities managed by this component
Used Integrations (1)
External integrations and APIs this component relies on