Registration
Before being able to authenticate using the Nevis Mobile Authentication SDK, go through the registration process. In the registration operation, FIDO UAF credentials are created on both mobile and server side. The credentials are used during authentication to validate that the user provided valid authentication.
To do a registration operation, configure and
initialize the SDK to obtain a MobileAuthenticationClient java, swift, objc, flutter, react native.
The PIN and password authenticators are fully managed by the SDK: their contents are defined through the SDK during registration.
- The Nevis Mobile Authentication SDK allows registering only one authenticator of each type per user.
- The PIN authenticator is fully managed by the SDK: its contents are defined through the SDK during registration.
- The device passcode authenticator uses the passcode to lock the device (PIN, password, gesture) which is defined in the operating system settings. The SDK does not manage this passcode.
- The biometric authenticators are managed by the operating system, thus to successfully register them, the end-user must previously define biometric credentials (fingerprint, face, iris) in the operating system settings.
Depending on the use case, there are two types of registration: in-app registration and out-of-band registration. For more information, see Registration.
Secure Defaults
The SDK uses "secure default" to provide the highest security with drawbacks regarding usability for end-users. The following settings influence the biometric authenticators and are listed with the default values used.
- The SDK does not allow Android class 2 sensors with
allowClass2Sensors(false)(Android only) java, flutter, react native - The SDK does not allow to use the device passcode as fallback during biometric authentication with
allowDevicePasscodeAsFallback(false)java, swift, objc, flutter, react native - The SDK invalidates biometric authenticators when OS biometrics are changed with
invalidateOnNewOsBiometrics(true)java, swift, objc, flutter , react native - The SDK attempts to use StrongBox to store key material (Android only). If StrongBox is not available or key creation fails, the SDK falls back to TEE. Both options are hardware-backed; the private key never leaves the secure hardware.
allowStrongBox(false)opts out of StrongBox and always uses TEE, which maximizes device compatibility. For details on the trade-offs and a decision guide, see StrongBox on Android.
- The
invalidateOnNewOsBiometricsandallowDevicePasscodeAsFallbackflags are mutually exclusive on Android SDK 3.7.0 and above; setting both totruewill throw aRuntimeException. - On iOS SDK 4.1.x and below,
allowDevicePasscodeAsFallbackoverridesinvalidateOnNewOsBiometricsif both are set totrue. Starting with iOS SDK 4.2.0, the flags are mutually exclusive; setting both totrueis not allowed. - When
invalidateOnNewOsBiometricsis set totrue, the SDK does not automatically remove invalidated authenticators - neither locally nor in the backend. When trying to access an invalidated authenticator, the SDK will throw anOperationErrorwith error codeFidoErrorCode.KEY_PERMANENTLY_DELETED. invalidateOnNewOsBiometricshas platform-specific behaviour: On Android removing biometrics (Fingerprints) does not invalidate other existing credentials as opposed to iOS where removal also leads to invalidation.