Table of Contents
Introduction à l'authentification biométrique sur iOS
Pour les développeurs iOS, le cadre d'authentification locale fournit une API simple et puissante pour intégrer Touch ID, Face ID et la vérification de code passe de périphérique dans les applications. Cet article passe par le processus complet de mise en œuvre de l'authentification biométrique à l'aide de LocalAuthentication, depuis la configuration initiale jusqu'aux meilleures pratiques prêtes à la production, en veillant à ce que votre application réponde aux normes les plus élevées de confidentialité et de sécurité des utilisateurs.
À la fin de ce guide, vous comprendrez comment vérifier la disponibilité biométrique, inciter les utilisateurs à l'authentification, gérer les erreurs gracieusement et fournir des mécanismes de repli – tout en suivant les lignes directrices Apple pour la protection des données et la vie privée des utilisateurs.
Comprendre le cadre d'authentification locale
Le cadre d'authentification local, introduit dans iOS 8, fournit une interface unifiée pour évaluer l'identité des utilisateurs par la biométrie ou un code passe-passe de périphérique. Il résume les différences matérielles sous-jacentes entre Touch ID et Face ID, vous permettant d'écrire une logique d'authentification qui fonctionne de manière transparente sur tous les appareils iOS pris en charge.
Les principaux éléments du cadre sont les suivants :
- LAContext: L'objet central qui gère les politiques d'authentification, les chaînes de raison localisées et le comportement de repli.
- LAPolitique:[ Les politiques prédéfinies qui déterminent la méthode d'authentification sont (biométrie seulement) et (biométrie avec rétroactivité du code d'accès).
- LAError: Codes d'erreur qui informent votre application pourquoi l'authentification a échoué—biométrie non disponible, utilisateur annulé, pas de code de passe non défini, et autres.
Bien que le cadre soit simple à utiliser, une mise en œuvre appropriée exige une attention particulière à l'expérience utilisateur, au traitement des erreurs et à la sécurité.
Politiques d'authentification expliquées
- – Si la biométrie (Touch ID ou Face ID) est inscrite et disponible, cette politique invite l'utilisateur à la vérification biométrique seulement. Si la biométrie n'est pas disponible, l'évaluation de la politique échoue sans offrir de retour en arrière de code de passe. Ceci est adapté pour les opérations à faible risque où vous voulez une expérience sans friction et peut gérer le manque de biométrie gracieusement.
- – Cette politique tente d'abord la vérification biométrique. Si la biométrie n'est pas disponible, l'utilisateur échoue à s'inscrire ou annule l'invite biométrique, votre application peut revenir au code d'accès de l'appareil. C'est la politique recommandée pour la plupart des scénarios d'authentification car elle garantit que même lorsque la biométrie n'est pas une option, l'utilisateur peut encore authentifier en utilisant son code d'accès.
Il est important de noter que le code passe n'apparaît qu'après que l'utilisateur annule l'invite biométrique ou si la biométrie échoue et que l'utilisateur touche -Enter Passcode.- Vous devez gérer ces événements correctement pour éviter de confondre l'utilisateur.
Mise en œuvre étape par étape
La mise en oeuvre de l'authentification biométrique comporte cinq étapes claires : importer le cadre, créer une instance , vérifier si la politique souhaitée peut être évaluée, effectuer l'évaluation et gérer le résultat. Voici une ventilation détaillée avec des exemples de code.
1. Importer le cadre
Commencez par importer dans tout fichier Swift où vous prévoyez d'utiliser l'authentification. Cette importation vous donne accès à , et à tous les types d'erreur.
import LocalAuthentication2. Créer un LAContext
est l'objet qui interroge l'état du système et effectue l'évaluation d'authentification. Vous pouvez en option configurer des propriétés telles que (le message montré à l'utilisateur) et (le texte du bouton fallback). Par exemple, vous pouvez changer le titre fallback en -Utilisez le code Pass - -Utilisez le mot de passe --Enter par défaut.
let context = LAContext()
context.localizedFallbackTitle = "Use Passcode"3. Vérifier la disponibilité biométrique
Avant d'inviter l'utilisateur, vous devez vérifier si la politique choisie peut être évaluée. Cette vérification est essentielle pour éviter une défaillance brutale qui pourrait confondre l'utilisateur. Utilisez la méthode , en passant la politique que vous comptez utiliser. La méthode renvoie une valeur booléenne. Si elle retourne , le paramètre (un pointeur) contiendra des détails sur la raison pour laquelle l'évaluation n'est pas possible.
var error: NSError?
let canEvaluate = context.canEvaluatePolicy(.deviceOwnerAuthentication, error: &error)
if !canEvaluate {
// Handle the error – see section on error handling below
print("Authentication not available: \(error?.localizedDescription ?? "Unknown error")")
return
}Les raisons courantes de l'échec sont les suivantes : l'appareil ne supporte pas la biométrie, aucune empreinte digitale ou faciale n'est inscrite, le code d'accès de l'appareil n'est pas défini ou l'application n'a pas droit à l'identifiant de visage (voir les pratiques exemplaires).
4. Évaluer la politique
Une fois que vous avez confirmé que la politique peut être évaluée, appelez . Le paramètre est une chaîne qui explique pourquoi votre application a besoin d'authentification. Cette chaîne doit être claire et conviviale parce qu'elle est affichée dans l'invite système. Pour Face ID, la raison est toujours affichée; pour Touch ID, elle peut être affichée en fonction de la configuration du périphérique.
context.evaluatePolicy(.deviceOwnerAuthentication, localizedReason: "Authenticate to access your secure data") { success, evaluateError in
DispatchQueue.main.async {
if success {
// Authentication successful
print("User authenticated successfully")
} else {
// Authentication failed or was cancelled
print("Authentication failed: \(evaluateError?.localizedDescription ?? "Unknown error")")
}
}
}Notez que le gestionnaire de l'achèvement n'est pas garanti pour fonctionner sur le thread principal. Toujours envoyer des mises à jour de l'interface utilisateur et la logique ultérieure à la file d'attente principale, comme indiqué ci-dessus.
5. Gérer le résultat
Lorsque l'authentification réussit, vous pouvez en toute confiance autoriser l'accès à des contenus ou actions protégés. Lorsqu'elle échoue, vous devez déterminer la cause en inspectant le . L'erreur sera de type , qui est un énum conforme à . Les cas courants comprennent :
- .utilisateurAnnuler:[ L'utilisateur a tapé -Annuler sur l'invite biométrique. Vous pouvez simplement rejeter le flux de connexion ou réessayer.
- .userFallback: The user tapped the fallback button (e.g., “Enter Password”). This triggers the passcode entry if using
.deviceOwnerAuthentication, but if you only used.deviceOwnerAuthenticationWithBiometrics, no fallback occurs. In that case, you should present your own passcode entry screen. - .biometryNotAvailable: Biometry is not available on this device (e.g., missing hardware). You should switch to passcode-only authentication.
- .biometryNotEnrolled: No biometric data is enrolled. Prompt the user to set up Touch ID or Face ID in Settings.
- .biometryLockout: Too many failed attempts; the system has locked biometry. You need to fall back to the passcode. The system passcode will reset the lockout.
- .passcodeNotSet: The device has no passcode configured. The user must set a passcode for biometry to work. Display an alert directing them to Settings.
Handling each of these cases gracefully is essential for a smooth user experience. For a production app, consider centralising your authentication logic in a manager class and providing clear feedback to the user.
Complete Example with Error Handling
Below is a more complete example that demonstrates a real-world authentication flow. It checks availability, handles errors with appropriate user alerts, and provides a fallback to a custom passcode entry if the user cancels biometry.
import LocalAuthentication
import UIKit
class BiometricAuthManager {
static let shared = BiometricAuthManager()
private let context = LAContext()
func authenticate(completion: @escaping (Bool, String?) -> Void) {
var error: NSError?
context.localizedFallbackTitle = "Use Passcode"
guard context.canEvaluatePolicy(.deviceOwnerAuthentication, error: &error) else {
// Determine the reason why authentication is unavailable
let message = errorMessage(for: error)
completion(false, message)
return
}
// Possibly show a loading state
context.evaluatePolicy(.deviceOwnerAuthentication, localizedReason: "Authenticate to access your account") { success, evaluateError in
DispatchQueue.main.async {
if success {
completion(true, nil)
} else {
let message = self.errorMessage(for: evaluateError as? LAError)
completion(false, message)
}
}
}
}
private func errorMessage(for error: LAError?) -> String {
guard let error = error else {
return "Authentication could not be completed."
}
switch error.code {
case .biometryNotAvailable:
return "Biometric authentication is not available on this device."
case .biometryNotEnrolled:
return "No biometric data is enrolled. Please set up Face ID or Touch ID in Settings."
case .biometryLockout:
return "Too many failed attempts. Please use your passcode to unlock biometrics."
case .passcodeNotSet:
return "A device passcode is required to use biometric authentication."
case .userCancel:
return "Authentication cancelled by user."
case .userFallback:
return "User chose to use the passcode."
default:
return "Authentication failed: \(error.localizedDescription)"
}
}
}Cette classe encapsule la logique d'authentification et renvoie un résultat de réussite/échec propre avec un message convivial. Vos contrôleurs de vue peuvent appeler et réagir en conséquence.
Meilleures pratiques et considérations en matière de production
Bien que le code ci-dessus offre une base solide, plusieurs autres pratiques vous permettront d'assurer une mise en œuvre robuste, sécurisée et conviviale.
Toujours fournir un code de passe Fallback
Même si vous utilisez la politique , vous devriez avoir votre propre écran d'entrée de code passe prêt. Beaucoup d'utilisateurs peuvent ne pas avoir de biométrie inscrite ou peuvent préférer utiliser un code passe dans certaines situations.
Utiliser une raison de description localisée
La chaîne est affichée dans l'invite système. Cette chaîne doit être concise et spécifique à l'action que l'utilisateur est sur le point d'autoriser. Par exemple, -Se connecter à votre compte est mieux qu'une vague Authentification requise.-- Localiser également cette chaîne pour différentes langues.
Respecter la confidentialité de l'utilisateur
Ne gardez jamais les données biométriques (modèles d'empreintes digitales ou cartes de visage) vous-même. Le système gère ces données de manière sécurisée sur l'Enclave sécurisée. Votre application ne reçoit qu'un résultat booléen succès/échec, et non les données biométriques réelles.
Essai sur des dispositifs réels
Le simulateur a des capacités de simulation biométriques limitées. Toujours tester Touch ID et Face ID sur les iPhones et iPads réels. Pour Face ID, vous devez également inclure la touche dans votre ; sinon, l'application va s'écraser lorsque vous essayez d'évaluer Face ID.
Gérer le cycle de vie de l'application
Si votre application utilise l'authentification biométrique pour sécuriser un état de fond, envisagez de ré-authentifier lorsque l'application retourne au premier plan. Vous pouvez observer et demander à nouveau l'authentification. Cependant, évitez de demander trop fréquemment l'authentification – un modèle commun est d'exiger une nouvelle authentification seulement après une période de temps.
Combiner avec la porte-clés pour une sécurité plus forte
Pour la sécurité persistante (par exemple, stocker des jetons API), combiner la biométrie avec la Keychain. Utilisez la classe avec les drapeaux ou pour s'assurer que les secrets stockés ne peuvent être accessibles qu'après une authentification biométrique ou un code passe réussie. La Keychain agit alors comme une voûte sécurisée qui se verrouille automatiquement lorsque l'appareil est verrouillé.
Retour après le verrouillage
Lorsque la biométrie est verrouillée en raison de trop de tentatives ratées, vous devez revenir au code passe de l'appareil. L'entrée du code passe système réinitialise automatiquement le lock-out biométrique, de sorte qu'après une entrée réussie du code passe, les futures tentatives biométriques fonctionneront à nouveau.
Différences entre l'ID tactile et l'ID visage
Bien que le cadre d'authentification locale résume la plupart des différences, il y a quelques nuances à garder à l'esprit:
- Le code d'identification de la façade nécessite un appareil avec une caméra TrueDepth Vous devriez vérifier après avoir appelé pour déterminer quel type biométrique est disponible.
- L'identifiant de la façade est plus sensible aux déplacements. L'utilisateur doit regarder directement l'appareil. Assurez-vous que votre explique pourquoi l'application a besoin d'un identifiant de visage.
- Exemple alternatif pour Face ID:[ iOS 15.4 et plus tard permettent aux utilisateurs de configurer une apparence alternative (par exemple, avec des lunettes ou un masque).Votre application n'a pas besoin de faire quoi que ce soit de spécial; le système le gère automatiquement.
- Masque support avec Face ID: Les versions iOS récentes supportent le déverrouillage avec un masque à l'aide de l'Apple Watch. Pour l'authentification au niveau de l'application, l'invite Face ID standard peut encore nécessiter une reconnaissance du visage complet à moins que l'utilisateur ait opté pour l'utilisation du masque avec Apple Watch.
Erreur lors de la plongée profonde
Nous avons brièvement abordé les erreurs courantes, mais il est utile de préciser comment réagir à chacune d'elles de manière conviviale.
| Error Code | User Feedback |
|---|---|
biometryNotAvailable | Show an alert: “Face ID / Touch ID is not available on this device. Please use your passcode.” Then offer your custom passcode screen. |
biometryNotEnrolled | Present an alert that directs the user to Settings > Face ID & Passcode (or Touch ID & Passcode). You can open Settings directly using UIApplication.openSettingsURLString. |
biometryLockout | Prompt the user to authenticate using the device passcode. The system passcode entry will reset the lockout. If you use the .deviceOwnerAuthentication policy, the system automatically handles the passcode prompt. If you used .deviceOwnerAuthenticationWithBiometrics, you must fall back to your own passcode entry or invoke the .deviceOwnerAuthentication policy again to trigger the system passcode UI. |
passcodeNotSet | Alert the user that a device passcode is required. Direct them to Settings to set one. You cannot continue until the passcode is configured. |
userCancel | Simply dismiss or return to the previous screen. Do not show an error; the user intentionally cancelled. |
userFallback | The user chose the fallback option. Present your own passcode entry screen (or rely on the system passcode if you used the combined policy). |
Performance et filage
La méthode est asynchrone et ne bloque pas le thread principal. Cependant, le gestionnaire d'achèvement peut être appelé sur un thread de fond. Toujours envoyer des mises à jour de l'interface utilisateur dans la file d'attente principale. De plus, évitez de créer un nouveau pour chaque tentative d'authentification; réutiliser une instance si possible, mais soyez conscient que le contexte peut devenir invalide après un verrouillage biométrique ou un redémarrage de l'appareil.
Essais d'authentification biométrique
Vous pouvez simuler l'authentification biométrique dans le Simulator iOS en utilisant le menu Hardware. Pour Touch ID, vous pouvez choisir -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
De plus, vous pouvez utiliser les plans de test Xcode-S pour écrire des tests unitaires autour de votre gestionnaire d'authentification en vous moquant de la classe , à condition de concevoir votre code avec injection de dépendance. Cela vous permet de tester la logique de gestion des erreurs sans vous fier au matériel réel.
Ressources extérieures
Pour plus de détails et de documentation officielle, voir les documents suivants:
- Apple= Documentation d'authentification locale
- Référence de classe LAContext[
- WWDC 2017 – Applications de construction avec carte d'identité faciale
- Services à chaîne-clé et contrôle d'accès biométrique
Conclusion
La mise en œuvre de l'authentification biométrique avec le cadre d'authentification local est un processus simple qui améliore considérablement votre posture de sécurité de l'application iOS tout en maintenant une expérience utilisateur fluide. En vérifiant la disponibilité, en manipulant les erreurs gracieusement et en fournissant des options de repli fiables, vous pouvez construire un système d'authentification qui respecte la confidentialité des utilisateurs et respecte les directives strictes d'Apple.
N'oubliez pas que l'authentification biométrique n'est qu'un élément d'une stratégie de sécurité complète. Combinez-le avec un stockage sécurisé via la chaîne-clés, la sécurité du réseau et la gestion de session appropriée pour offrir à vos utilisateurs le niveau de protection le plus élevé. Avec le code et les meilleures pratiques partagés dans cet article, vous êtes bien équipé pour intégrer Touch ID et Face ID dans votre prochain projet iOS.