Supabase Auth
Authentication Provider Integration by Supabase Inc.
Description
Supabase Auth manages the session lifecycle for all authenticated users, bridging BankID, Vipps Login, and email/password credentials into a unified JWT-based session. It issues and refreshes JWTs consumed by RLS policies on every database query, providing the backbone of multi-tenant access control across all organisations.
Detailed Analysis
Supabase Auth is the identity backbone of the platform, unifying Norwegian national identity providers — BankID and Vipps Login — with email/password credentials into a single JWT-based session model. This means users authenticate once using methods they already trust (bank-grade identity verification) and gain seamless access across the entire platform without additional credential management. For organisations handling sensitive personal data of vulnerable individuals, BankID-level identity assurance significantly reduces fraud risk and strengthens compliance posture. The JWT sessions directly power Row-Level Security on every database query, ensuring that authentication and data access control are architecturally inseparable.
Included in the Supabase subscription with MAU-based overages, cost scales linearly with user adoption. The biometric re-authentication fallback reduces support burden by enabling session recovery without full re-login workflows.
Supabase Auth is a hard dependency for all application functionality — auth failure blocks every feature. This makes its 99.9% availability requirement non-negotiable, and delivery planning must account for BankID and Vipps provider configuration in the Supabase dashboard as an external dependency that may require vendor coordination and testing time. Nine components depend on this integration, including the session manager, token store, and secure storage adapter. PKCE flow configuration for OAuth redirects and JWT expiry/refresh settings must be validated across all supported authentication paths.
flutter_secure_storage integration (iOS Keychain / Android Keystore) requires platform-specific testing and entitlement configuration. Ongoing maintenance includes monitoring auth error rates, token refresh latency, and refresh token exhaustion alerts. The team needs familiarity with OAuth 2.0 / PKCE flows and Supabase Auth provider configuration.
Supabase Auth v2 (GoTrue) is consumed via the supabase_flutter SDK, which handles the full session lifecycle including initial authentication, silent JWT refresh, and logout. JWTs are persisted in flutter_secure_storage (iOS Keychain, Android Keystore) — never in SharedPreferences or in-memory only. The SDK auto-refreshes expiring tokens transparently before any outgoing request; AuthException is caught and mapped to user-facing messages with specific error codes. Refresh tokens rotate on every use (refresh token rotation enabled).
PKCE flow is used for all OAuth provider redirects (BankID, Vipps) to prevent authorisation code interception. Session state is managed by 037-supabase-session-manager and exposed to the app via 024-auth-session-manager with stream-based reactive updates. Biometric re-authentication via 034-session-resume-manager allows recovery from a cached session without a full re-login round-trip. Auth service availability is monitored via the Supabase status page; spike alerts on authentication failures trigger incident response.
Using Components (9)
Dependencies (3)
Authentication
| Type | Jwt |
| Requirements | Supabase project URL, Supabase anon API key, JWT secret configured for token verification |
| Scopes | authenticatedanon |
Configuration
SUPABASE_URL
SUPABASE_ANON_KEY
Error Handling
Monitoring
Performance
| Latency | < 500ms for token refresh, < 2s for initial authentication |
| Availability | 99.9% availability required — auth failure blocks all app functionality |
Cost Implications
| Pricing Model | Included in Supabase subscription |