Enable Biometric Login After Initial BankID/Vipps Authentication
After successfully authenticating via BankID or Vipps for the first time, the app presents an option to enable biometric authentication (Face ID or fingerprint/Touch ID) for future logins. The biometric auth service uses the device's local authentication framework to verify the user, with the auth session token stored securely. On subsequent app launches, the user is authenticated via biometrics rather than going through the full BankID or Vipps flow again. If biometrics fail or are unavailable, the user can fall back to the full BankID/Vipps flow.
User Story
Audience Summaries
Biometric login is a critical retention feature explicitly requested by all three partner organizations and directly addresses the core friction point in returning-user sessions. For a volunteer app used predominantly on mobile, requiring a full BankID or Vipps flow on every launch would cause significant abandonment — volunteers already give their time freely, and authentication friction compounds dropout. By enabling Face ID or fingerprint access after an initial verified BankID or Vipps session, the app delivers the frictionless re-engagement pattern users already expect from Norwegian banking apps. This lowers the daily barrier to usage, increases session frequency, and supports partner organizations' goals of sustained volunteer engagement.
The fallback mechanism ensures strong identity assurance is never fully bypassed, protecting organizational trust and data security posture while preserving excellent user experience.
This story has a hard dependency on stories 002 and 003 of the BankID/Vipps login feature, and must be sequenced after those auth flows are stable and tested. Delivery requires coordination across both iOS and Android platforms, as the biometric implementation paths differ — Face ID/Touch ID on iOS via LocalAuthentication framework and fingerprint/biometrics on Android via BiometricPrompt API. QA must cover six distinct acceptance scenarios including the three-failure fallback threshold, device-without-biometrics graceful degradation, and secure token storage verification. UAT should include volunteers from each of the three partner organizations to confirm the opt-in UX is clear and trustworthy.
The highest delivery risk is cross-platform secure token storage behavior, which requires security review. Estimate two to three sprint cycles including integration testing and partner sign-off.
Implementation requires a BiometricAuthService abstraction that wraps platform-specific APIs — iOS LocalAuthentication (LAContext) and Android BiometricPrompt — behind a unified interface. On opt-in, the service must securely store the existing session token in the platform keychain (iOS Keychain Services or Android Keystore), never in shared storage or AsyncStorage. The biometric prompt overlay must be rendered before the auth method selector on app launch when biometrics are enabled, with a clearly defined state machine covering: no preference set, enabled + available, enabled + unavailable, and locked-out-after-failures. The three-consecutive-failure lockout requires a counter stored alongside the preference.
Fallback routing must cleanly re-enter the existing BankID/Vipps auth flow without state corruption. Edge cases include biometric enrollment changes (new fingerprint added to device), app reinstall clearing preferences, and OS-level biometric lockout events.
Acceptance Criteria
- Given I have just completed BankID or Vipps login for the first time, When authentication succeeds, Then I am offered the option to enable biometric login with a clear explanation
- Given I opt in to biometric login, When I confirm, Then the biometric auth service registers my biometric preference and stores my session token securely
- Given biometric login is enabled, When I open the app on subsequent sessions, Then the biometric prompt overlay is shown immediately instead of the auth method selector
- Given I authenticate with Face ID or fingerprint, When biometric verification succeeds, Then my session is restored and I am taken to the role-based home screen
- Given biometric authentication fails three consecutive times, When the threshold is exceeded, Then I am shown a fallback option to re-authenticate via BankID or Vipps
- Given my device does not support biometrics, When the setup step is reached, Then the biometric unavailable banner is shown and the option is gracefully skipped
Business Value
All three partner organizations explicitly requested biometric login as the expected post-initial-login experience. For a volunteer app used primarily on mobile, requiring full BankID or Vipps authentication on every session would cause severe friction and abandonment. Biometric login after verified initial authentication strikes the right balance: strong identity assurance at first login, then rapid frictionless access on returning sessions — matching the UX pattern of Norwegian banking apps users already know.
Components
- Biometric Authentication Screen ui
- Biometric Authentication Service service
- Biometric Authentication Service service
- Biometric Prompt Overlay ui
- Biometric Unavailable Banner ui
- Session Resume Manager service
- Secure Session Storage data
- Local Auth Integration infrastructure
- Supabase Session Manager infrastructure
- Auth Token Store data
- Secure Storage Adapter infrastructure
- Biometric Authentication Service service
Dependencies
- Authenticate Using BankID critical
- Authenticate Using Vipps critical