Authentication Modes and Biometry
Authentication Modes
For a KOBIL Digitanium+ environment the LoginWithTokenEvent takes an AuthenticationMode as parameter. Similarly, for a KOBIL Shift Lite environment, the SetAuthorisationCodeEvent takes this parameter.
The AuthenticationMode can take one of the following three values:
AuthenticationMode.NO
AuthenticationMode.BIOMETRIC
AuthenticationMode.PASSWORD
- when using AuthenticationMode.NO, the MC will save the token data when triggering a LoginWithTokenEvent with full parameters (accessToken and authCode) and it will try to use the saved token data to perform subsequent Logins when triggering a LoginWithTokenEvent without accessToken and authCode.
- when using AuthenticationMode.BIOMETRIC, the MC will add another layer of protection to the saved token data and will need a successful biometric authentication before perform a login.
Note: If opting to use the biometric authentication mode on Android you need to add androidx.biometric:biometric-ktx dependency to your Android app:
dependencies {
...
implementation 'androidx.biometric:biometric-ktx:1.2.0-alpha03'
...
}
Note: The authentication mode can be switched at any time, except during an ongoing activation. Starting with MC SDK 14.1 users can temporarily switch from AuthenticationMode.BIOMETRIC to AuthenticationMode.PASSWORD. In all versions prior to 14.1 switching from AuthenticationMode.BIOMETRIC to AuthenticationMode.PASSWORD results in loosing the tokens of the previously enabled biometric login, this means users have to setup biometry anew if they choose to switch back to AuthenticationMode.BIOMETRIC afterwards.
Biometry Error Handling
When using AuthenticationMode.BIOMETRIC for authentication on a KOBIL Digitanium+ or KOBIL Shift Lite environment you will have to handle biometry related results and error codes. The SDK passes down the default codes of the used operating system with a leading 3 digit number. After removing the leading 3 digits you can handle as you would do when directly working with the corresponding OS API. Depending on your needs you can assign the error code to different app handling
- Biometry canceled (by user or operating system): App can decide to retry.
- Biometry failed (detection not possible): App should ask to retry.
- Biometry failed (perhaps an attack): App can decide to retry (but countermeasures against attacks might be needed).
- Biometry currently not available: App should ask the user to setup the biometry on operation system.
- Biometry not available: Supported Biometry technics was not available on this device, app has to disable biometry.
There is a flow in iOS that developers need to handle with a biometry prompt. When the native biometric prompt gets interrupted by a call or putting an application in the background. This makes OfflineLoginEvent or SetAuthorizationCodeEvent gets failed and a developer will receive one of the canceled error codes:
- userCanceled = 128
- userCanceledSE = 2
- systemCanceled = 4
- appCanceled = 9
When the developer receives those errors he should restart the process.