Авторизація за Touch ID та Face ID в iOS: повне керівництво з реалізації

Розробка авторизації за біометрією (Touch ID) в iOS-додатку

Ми часто стикаємося з проєктами, де замовник хоче захистити доступ до додатку біометрією, але не враховує нюанси різних типів сенсорів. Touch ID старший за Face ID, але досі живий: iPhone SE 3rd gen, iPad mini 6, iPad 10th gen з бічним сенсором — це все діючий парк пристроїв у реальних користувачів. LAContext один і той самий, але поведінка відрізняється в деталях, які б'ють у продакшені. Наш досвід показує, що правильна реалізація економить години налагодження та підвищує довіру користувачів.

Чому варто обрати біометричну авторизацію?

Біометрія пришвидшує вхід, не знижуючи безпеки, якщо грамотно обробляти помилки та fallback. Touch ID особливо корисний в enterprise-сценаріях: доступ до медичних даних, фінансових операцій, корпоративної пошти. Ми гарантуємо, що ваш додаток буде готовий до будь-яких сценаріїв — від мокрих пальців до блокування сенсора.

Специфіка Touch ID проти Face ID

Головна відмінність — мультипальцева реєстрація. У користувача може бути до п'яти відбитків. При biometryType == .touchID і успішній аутентифікації ви не знаєте, який саме палець було використано — API цього не повертає. Для більшості сценаріїв це нормально, але в enterprise-додатках із журналом аудиту іноді хочуть логувати "який пристрій використовувався". Touch ID це не дозволяє за дизайном.

Друга відмінність — швидкість деградації. Вологі пальці, рукавички, порізи — Touch ID частіше переходить у fallback, ніж Face ID. Це означає, що .userFallback треба обробляти якісно, а не показувати кнопку "Введіть пароль" без пояснень.

Помилка, яку зустрічаю регулярно: розробник перевіряє biometryType один раз при запуску та кешує результат. Користувач додає новий відбиток у налаштуваннях — кеш застарів, запис Keychain із .biometryCurrentSet інвалідовано, додаток падає з errSecItemNotFound (-25300) при спробі дістати токен. Правильно: створювати новий LAContext перед кожною спробою аутентифікації та не зберігати контекст довше однієї транзакції.

Face ID швидше приблизно вдвічі, ніж Touch ID, що варто враховувати при виборі методу аутентифікації.

Як реалізувати Touch ID без болю?

Політика та сама — .deviceOwnerAuthenticationWithBiometrics. Але для Touch ID особливо важливий параметр localizedFallbackTitle у LAContext. Якщо поставити пустий рядок "" — кнопка fallback сховається повністю. Якщо не задати — з'явиться "Enter Password" (системний текст). Ставимо кастомний: "Увійти за PIN-кодом" або "Використати пароль додатку" — залежно від того, що у вас реалізовано.

Покрокова інструкція для Swift:

1. Імпортуйте LocalAuthentication та створіть LAContext.
2. Викличте canEvaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, error:) для перевірки доступності біометрії.
3. Якщо доступно, викличте evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, localizedReason: "Увійти за відбитком").
4. Обробте результати в замиканні: успіх — отримайте токен із Keychain, помилка — залежно від коду (lockout, cancel, fallback).

Зберігання секрету в Keychain під Touch ID:

var error: Unmanaged<CFError>? guard let access = SecAccessControlCreateWithFlags( kCFAllocatorDefault, kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly, [.biometryCurrentSet, .privateKeyUsage], &error ) else { /* handle */ } 

Прапорець .privateKeyUsage додається, якщо секрет використовується для крипто-операцій (підпис запитів). Для простого зберігання токена достатньо .biometryCurrentSet.

Бічний Touch ID (iPad, iPhone SE)

На iPad mini 6 та iPad 10th gen сенсор вбудовано в кнопку живлення. Анімація розблокування інша — користувач прикладає палець до бічної кнопки, а не до нижньої. Це впливає на те, як ви позиціонуєте підказки в UI. biometryType поверне .touchID в обох випадках — відмінностей в API немає, тільки в UX-копірайтингу.

Як гарантувати стабільність?

Тестуємо всі edge cases за чек-листом:

• Відбиток не розпізнано тричі поспіль → lockout → коректний перехід на fallback
• Touch ID вимкнено в налаштуваннях пристрою → .biometryNotAvailable
• Passcode не задано → canEvaluatePolicy поверне false з помилкою .passcodeNotSet
• Додаток переходить у background під час очікування Touch ID → .systemCancel

На симуляторі емулюємо через Features → Touch ID → Matching Touch / Non-matching Touch.

Що входить у роботу

• Інтеграція LocalAuthentication з обробкою всіх станів та error codes
• Зберігання токенів або ключів у Keychain з біометричним захистом
• Налаштування fallback-інтерфейсу (PIN-код / пароль додатку)
• Юніт-тести для кожного сценарію
• Документація з використання та можливих проблем

Вартість робіт — від $1000 до $2500 залежно від складності інтеграції. Запишіться на консультацію: ми оцінимо ваш проєкт та запропонуємо оптимальне рішення.

Терміни

Реалізація Touch ID-аутентифікації з Keychain-сховищем, обробкою всіх error states та unit-тестами — 2–5 робочих днів. Якщо потрібна інтеграція з існуючим auth-модулем або міграція з UserDefaults на Keychain — додаємо 1–2 дні на аудит та рефакторинг.

Наші інженери мають 7+ років досвіду в iOS-розробці та сертифікацію Apple. Зв'яжіться з нами, щоб замовити послугу.

let context = LAContext() var error: NSError? guard context.canEvaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, error: &error) else { // обробка недоступності return } context.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, localizedReason: "Увійдіть за відбитком пальця") { success, error in if success { // отримати токен з Keychain } else { // обробка error.code } } 

Джерело: LocalAuthentication Framework – Apple Developer Documentation Apple Inc.