Autenticazione biometrica con Face ID e Touch ID: quando usarla in un’app mobile

Il problema: un login sicuro che diventa una seccatura

Il login più sicuro del mondo non serve a molto se l’utente passa il tempo a cercare un modo per evitarlo.

In un’app aziendale questa situazione è più frequente di quanto si pensi. Un dipendente apre l’app per controllare una richiesta ferie, verificare un turno o consultare una comunicazione — un’operazione che dovrebbe richiedere pochi secondi. Se a ogni accesso deve invece recuperare la password, attendere un codice OTP o ripetere l’intero flusso di autenticazione, la sicurezza rischia di trasformarsi in puro attrito, qualcosa da subire più che da apprezzare.

La conseguenza non è soltanto una cattiva esperienza d’uso, per quanto già di per sé fastidiosa. Gli utenti possono finire per scegliere password più semplici, riutilizzarle altrove, oppure lasciare l’app autenticata più a lungo del necessario pur di non ripassare da quel percorso. In altre parole, un meccanismo pensato per proteggere l’account può, paradossalmente, incoraggiare comportamenti meno prudenti di quelli che vorrebbe prevenire.

Face ID, Touch ID e gli altri sensori biometrici possono ridurre questo problema. Ma la domanda giusta da porsi non è “possiamo aggiungere un pulsante per accedere con il volto o con l’impronta?”. La domanda è piuttosto: in quale punto del flusso la biometria migliora davvero il livello di sicurezza, senza al tempo stesso introdurre nuovi rischi che prima non c’erano?

Che cosa significa davvero “accesso biometrico”

Quando un’app usa Face ID o Touch ID, normalmente non riceve affatto l’immagine del volto o l’impronta dell’utente — un dettaglio che vale la pena chiarire subito, perché è alla base di tutto il resto. Il sistema operativo gestisce il confronto all’interno delle proprie componenti di sicurezza, e comunica all’app soltanto l’esito dell’operazione, oppure le consente l’accesso a una risorsa protetta.

Su iPhone e iPad, Apple descrive un modello in cui il Secure Enclave verifica il dato biometrico e restituisce semplicemente un risultato di successo o fallimento. I dati sottostanti, come le impronte registrate, non sono mai disponibili all’app che le richiede. Su Android, l’applicazione utilizza il prompt biometrico di sistema, e può definire quali autenticatori sono ammessi — inclusa, quando appropriato, la credenziale generica del dispositivo.

Questo è un punto essenziale, e va tenuto ben presente: la biometria non dovrebbe mai diventare una nuova password da copiare sul server. Non si dovrebbe memorizzare un’immagine del volto, un’impronta o un ipotetico “codice biometrico” nel database dell’app — sarebbe un errore concettuale, oltre che di sicurezza.

In un’architettura corretta, il primo accesso avviene con il metodo già previsto — password e OTP, per esempio. Solo dopo questo accesso l’utente può attivare volontariamente l’autenticazione biometrica sul proprio dispositivo. Da quel momento in poi, la biometria serve a sbloccare una chiave privata locale o ad autorizzare una sessione, non a sostituire il sistema di identità gestito dal server.

Il modello più solido: biometria locale e challenge del server

Per un’app che deve proteggere dati personali e informazioni aziendali, il flusso più consigliabile si basa su una coppia di chiavi crittografiche, e funziona più o meno così: l’utente completa il login iniziale con password, OTP o un altro fattore; l’app verifica che il dispositivo supporti la biometria e chiede se l’utente vuole abilitarla; sul dispositivo viene generata una coppia di chiavi, pubblica e privata; la chiave privata resta nel Keychain di iOS o nel Keystore di Android, protetta direttamente dal sistema operativo; la chiave pubblica viene associata all’account sul server; al successivo accesso il server invia una challenge casuale, breve e non riutilizzabile; l’utente supera il prompt biometrico; la chiave privata firma quella challenge senza mai essere esportata dal dispositivo; e infine il server verifica la firma usando la chiave pubblica, autorizzando l’accesso solo a quel punto.

Questo schema separa bene le responsabilità dei due lati: il dispositivo verifica la presenza fisica dell’utente davanti al device, mentre il server verifica che la risposta provenga effettivamente dalla chiave registrata per quell’account e per quel dispositivo specifico.

La challenge, perché il meccanismo regga davvero, deve essere generata dal server, avere una scadenza breve, e risultare inutilizzabile una seconda volta. Il payload può includere almeno un nonce, un timestamp o una scadenza, l’identificativo della sessione e il contesto dell’operazione in corso. Firmare sempre la stessa stringa, o un valore creato interamente dal client, non offre nessuna vera protezione contro il replay — è solo un simulacro di sicurezza.

Questo modello è ben diverso dal semplice “biometric prompt” che tanti tutorial mostrano come se fosse tutto. Un prompt che restituisce semplicemente true può essere sufficiente per sbloccare una schermata locale, quella sì. Ma per un login collegato a un account remoto, è molto meglio dimostrare al server che l’autenticazione ha sbloccato una chiave specifica, registrata in precedenza — non basta un generico “ok, era lui”.

Quando la biometria è una buona scelta

L’autenticazione biometrica è particolarmente adatta quando ricorrono alcune condizioni piuttosto concrete: l’app viene aperta spesso durante la giornata; il dispositivo è personale, o comunque assegnato stabilmente a un solo utente; l’app contiene dati che non dovrebbero essere visibili a chiunque prenda in mano il telefono; esiste già un login iniziale robusto, basato su password, OTP o identità aziendale; il server può verificare una challenge firmata, mantenendo così un controllo reale sull’autorizzazione; l’utente può disattivare la funzione e passare a un metodo alternativo senza problemi; e l’organizzazione ha già definito cosa succede in caso di smarrimento, cambio dispositivo o revoca dell’accesso.

In questo scenario la biometria funziona come una vera e propria ri-autenticazione locale. Non è necessariamente il primo fattore con cui si crea un account, e non elimina in alcun modo la necessità di poter revocare le sessioni lato server quando serve.

Per un’app HR, un esempio ragionevole è l’accesso quotidiano al proprio profilo, alle richieste di ferie o ai documenti personali. L’utente si autentica la prima volta con il metodo classico, e nelle aperture successive conferma semplicemente la propria presenza sul dispositivo in pochi secondi, senza dover ripetere l’intero rito ogni volta.

Quando è meglio non abilitarla

La biometria non è una risposta automatica valida per ogni applicazione, e sarebbe un errore trattarla come tale. È opportuno evitarla, o quantomeno limitarla a operazioni specifiche, in diversi casi.

Sui dispositivi condivisi, per esempio — pensiamo a un tablet usato da più persone — abilitare il login biometrico rischia di collegare l’account sbagliato al dispositivo, o di rendere poco chiara la responsabilità dell’accesso avvenuto. In questo caso conta molto di più un flusso esplicito di cambio utente e logout, ben visibile e facile da usare.

Lo stesso vale per gli account collettivi: un account condiviso non diventa magicamente sicuro solo perché viene sbloccato con un volto o un dito. La biometria è legata alla configurazione del singolo dispositivo, mentre l’account dovrebbe sempre rappresentare una persona identificabile — le due cose, in un account collettivo, semplicemente non si allineano.

Anche le operazioni ad alto impatto meritano una riflessione a parte. Per cambiare dati bancari, approvare un pagamento, firmare un documento o eseguire un’operazione irreversibile, può essere necessario un fattore aggiuntivo, una conferma esplicita, o comunque una procedura più solida di un semplice sblocco biometrico. La comodità pensata per il login quotidiano non va trasferita automaticamente a ogni azione successiva, anche quella più delicata.

Attenzione poi agli ambienti in cui il fallback è debole: se il percorso alternativo è un PIN facilmente osservabile da chi sta accanto, una password già memorizzata da tempo o un meccanismo che l’app gestisce male, il livello di protezione reale può scendere invece che salire. Il fallback deve essere coerente con il rischio dell’operazione, non pensato solo per evitare qualche ticket di assistenza in più.

Infine, ci sono i requisiti di accessibilità e le condizioni operative variabili da tenere sempre a mente: un sensore può semplicemente non essere disponibile, l’utente può non poterlo utilizzare per ragioni diverse, oppure il sistema può richiedere il codice del dispositivo dopo un riavvio, troppi tentativi falliti o una modifica delle credenziali biometriche registrate. Il percorso alternativo non è un’eccezione rara da gestire alla bell’e meglio: fa parte del prodotto a tutti gli effetti, e va progettato con la stessa cura del percorso principale.

Sicurezza contro comodità: il vero trade-off

La biometria migliora la sicurezza soprattutto perché riduce la tentazione di usare password deboli, e rende più semplice bloccare l’accesso all’app quando serve davvero. Il sistema operativo, in più, può applicare limiti ai tentativi, richiedere periodicamente il codice del dispositivo, e proteggere le chiavi tramite hardware dedicato a questo scopo.

Non significa, però, che Face ID o Touch ID rendano l’app invulnerabile — sarebbe un’illusione pericolosa da coltivare.

Chi entra in possesso di un dispositivo già sbloccato si trova comunque in una posizione privilegiata, biometria o meno. Un utente può, in teoria, essere costretto a presentare il volto o il dito contro la propria volontà. Un dispositivo sottoposto a root o jailbreak richiede valutazioni aggiuntive che vanno oltre il semplice sensore. La registrazione di una nuova impronta o di un nuovo volto può invalidare le chiavi protette, richiedendo una nuova autenticazione iniziale da capo. E infine, la chiave locale non revoca da sola una sessione che il server considera ancora perfettamente valida.

Per questo l’implementazione deve prevedere, come minimo, alcune protezioni di base: scadenza e revoca delle sessioni gestite lato server; la possibilità di rimuovere un dispositivo associato all’account quando necessario; l’invalidazione delle chiavi nel momento in cui cambia la configurazione biometrica, se il sistema operativo lo segnala; il logout da tutti i dispositivi in caso di smarrimento del telefono; un fallback chiaro, ma non più debole del rischio che si sta cercando di gestire; una richiesta biometrica mostrata soltanto quando serve davvero, accompagnata da un messaggio comprensibile; e nessuna registrazione nei log di payload, chiavi private o informazioni sensibili di qualunque tipo.

Anche la frase mostrata nel prompt, per quanto possa sembrare un dettaglio secondario, conta più di quanto si pensi. “Autenticati per accedere ai tuoi dati” è molto più trasparente di un generico “Operazione richiesta” che non spiega nulla. L’utente deve poter capire perché il sensore viene attivato in quel momento, e quale risultato produce concretamente la sua autenticazione.

Le implicazioni privacy e legali: il consenso non è un pulsante magico

La parola “biometria” richiede particolare attenzione in un prodotto destinato alle aziende, e non va presa alla leggera solo perché tecnicamente comoda da implementare.

Il GDPR definisce i dati biometrici come dati personali ottenuti da uno specifico trattamento tecnico delle caratteristiche fisiche, fisiologiche o comportamentali di una persona, quando permettono o confermano l’identificazione univoca di quella persona. L’articolo 9 del GDPR include i dati biometrici usati per identificare univocamente qualcuno tra le categorie particolari di dati personali — quelle che richiedono attenzione rafforzata.

Questo non significa che ogni uso del sensore del telefono comporti automaticamente la raccolta, da parte dell’azienda, di un archivio di impronte o volti. Se il confronto rimane confinato nel dispositivo, e il server riceve soltanto una firma legata a una chiave pubblica, il trattamento è strutturalmente diverso da un sistema che raccoglie template biometrici centralizzati da qualche parte.

La differenza tecnica, però, non elimina affatto la necessità di una valutazione privacy vera e propria. Restano da chiarire, tra gli altri elementi, quali dati vengono associati all’account e al dispositivo, quali eventi di autenticazione vengono effettivamente registrati, chi è titolare e chi è responsabile del trattamento, quali sono finalità, tempi di conservazione e misure di sicurezza adottate, come vengono gestiti revoca, sostituzione del dispositivo e cancellazione dei dati, se il trattamento può richiedere una valutazione d’impatto formale, e quali informazioni devono comparire nell’informativa fornita all’utente.

Vale la pena distinguere con chiarezza due consensi che vengono spesso confusi tra loro. Il primo è il consenso tecnico del sistema operativo: l’utente autorizza semplicemente l’app a utilizzare Face ID, Touch ID o un altro autenticatore per sbloccare una risorsa specifica. Il secondo, ben diverso, è l’eventuale base giuridica privacy per i trattamenti svolti dall’organizzazione nel suo complesso. Il messaggio mostrato da iOS o Android non sostituisce l’informativa, e non risolve da solo la base giuridica prevista dal GDPR — sono due livelli distinti che vanno tenuti separati.

In ambito lavorativo bisogna essere ancora più prudenti su questo punto. Il consenso del dipendente non è automaticamente libero solo perché compare un checkbox da spuntare. L’EDPB richiama esplicitamente lo squilibrio di potere che esiste tra datore di lavoro e lavoratore: se il rifiuto può produrre uno svantaggio concreto, diventa difficile dimostrare che la scelta sia stata davvero libera, nel senso pieno che il GDPR richiede.

Il Garante italiano ha inoltre adottato provvedimenti specifici sul riconoscimento facciale usato per la rilevazione delle presenze. Il messaggio da trarre non è che ogni forma di autenticazione biometrica sia vietata in assoluto, ma che la biometria non diventa lecita soltanto perché il dipendente ha firmato un consenso, o perché esiste un’alternativa formalmente prevista sulla carta. Finalità, necessità, proporzionalità e reale libertà di scelta vanno sempre valutate nel contesto concreto in cui ci si trova, caso per caso.

Per un’app aziendale è quindi preferibile progettare la biometria come una funzione opzionale di accesso personale, tenuta ben separata dalla rilevazione delle presenze. Deve esistere un’alternativa realmente utilizzabile, e il rifiuto non dovrebbe mai impedire di usare il servizio, né creare conseguenze lavorative di alcun tipo. La formulazione finale dell’informativa e la scelta della base giuridica vanno comunque validate prima del rilascio, non sistemate a posteriori.

Perché scegliere react-native-biometrics

Nel progetto myGenius, la scelta di react-native-biometrics nasce da un’esigenza precisa: non limitarsi a mostrare un semplice prompt biometrico, ma collegare l’autenticazione a una coppia di chiavi e a una firma effettivamente verificabile dal server.

La libreria espone un’API React Native che fa da ponte verso le funzionalità native di iOS e Android. Tra le operazioni documentate ci sono la verifica della disponibilità del sensore tramite isSensorAvailable(), la generazione delle chiavi con createKeys(), il controllo dell’esistenza delle chiavi già create con biometricKeysExist(), la firma di un payload dopo il prompt con createSignature(), e la cancellazione delle chiavi con deleteKeys() quando serve ripartire da zero.

Questo approccio si adatta bene al flusso descritto sopra: la chiave privata rimane sempre nel keystore del dispositivo, mentre la chiave pubblica può essere tranquillamente registrata sul backend. La funzione createSignature(), però, non dovrebbe mai firmare una password o un valore statico — deve firmare una challenge fresca, inviata dal server proprio per quello scopo.

La libreria mette a disposizione anche un metodo più semplice per mostrare il solo prompt, senza il resto del meccanismo. Può essere utile per proteggere una schermata o un’azione interamente locale, ma non sostituisce la verifica server-side quando l’obiettivo è autenticare un account remoto — sono due usi diversi, con garanzie molto diverse tra loro.

Scegliere una dipendenza, va detto, non chiude il problema una volta per tutte. Prima dell’adozione in produzione vanno verificati lo stato di manutenzione del progetto, la compatibilità con la versione di React Native in uso, i requisiti minimi su iOS e Android, il comportamento sui dispositivi reali (non solo sul simulatore) e la gestione degli errori nei casi limite. L’adapter biometrico dovrebbe inoltre restare isolato dal resto dell’app: così, se un domani serve sostituire la libreria, non si è costretti a riscrivere l’intero flusso di autenticazione da capo.

Nel caso di iOS, la configurazione deve spiegare chiaramente all’utente perché l’app chiede di utilizzare Face ID. Su Android, invece, bisogna considerare le differenze tra classi di autenticazione, fingerprint, riconoscimento facciale e credenziale generica del dispositivo. Questi dettagli appartengono più alla guida pratica del prossimo articolo che a questo, ma incidono già, fin da ora, sulla decisione architetturale di fondo.

Una checklist prima di attivare la funzione

Prima di pubblicare il login biometrico, il team dovrebbe poter rispondere con chiarezza a queste domande:

1. L’utente ha completato almeno una volta un’autenticazione iniziale affidabile?
2. La funzione è opzionale e può essere disattivata senza penalizzazioni?
3. La chiave privata resta sempre nel keystore nativo?
4. Il server verifica una challenge a scadenza breve e impedisce il replay?
5. Cosa succede se non esiste un sensore, se l’utente nega il permesso o se falliscono i tentativi?
6. Cosa succede dopo il logout, la disinstallazione, la perdita del telefono o il cambio di device?
7. È possibile revocare una singola chiave dal backend?
8. Il fallback è adeguato al valore dei dati e delle operazioni protette?
9. L’informativa privacy distingue l’autenticazione locale dalla raccolta di dati biometrici?
10. Il flusso è stato testato su dispositivi reali, non soltanto su simulatore?

Se anche una sola risposta manca, la funzionalità non è ancora pronta per andare in produzione. Il sensore può anche funzionare perfettamente sul piano tecnico, ma il sistema di autenticazione nel suo complesso resterebbe comunque incompleto.

Conclusione: la biometria deve togliere attrito, non aggiungere ambiguità

Face ID e Touch ID sono utili quando risolvono un problema concreto: permettere a una persona già autenticata di tornare nell’app in modo rapido, senza ridurre il controllo sull’account e senza trasferire dati biometrici al server — nessuno di questi due aspetti va sacrificato per l’altro.

La soluzione migliore non consiste nel sostituire password e OTP in ogni circostanza possibile. Consiste, piuttosto, nel combinare un’autenticazione iniziale solida, chiavi protette dal dispositivo, una challenge verificata server-side, la revoca delle sessioni quando serve, e un percorso alternativo che sia realmente praticabile, non solo previsto sulla carta.

Per un’app aziendale, la parte tecnica è soltanto metà del lavoro da fare. L’altra metà riguarda il contesto in cui quella tecnologia viene calata: chi usa davvero il dispositivo, quali dati vengono protetti, quale rischio si vuole ridurre, e se l’utente può scegliere liberamente senza subire conseguenze. Un’implementazione biometrica ben progettata è quella che rende l’accesso più semplice, senza mai trasformare il volto o l’impronta di qualcuno in un nuovo archivio aziendale da gestire.

In un prossimo articolo vedremo l’integrazione pratica di Face ID e Touch ID in React Native: controllo del sensore, generazione delle chiavi, firma della challenge e fallback su PIN o credenziali.

Domande frequenti

• Regolamento (UE) 2016/679 — GDPR, EUR-Lex

• EDPB — Biometrics
• EDPB — Guidelines 05/2020 on consent
• Garante per la protezione dei dati personali — Provvedimento del 22 febbraio 2024
• Apple Developer — Accessing Keychain Items with Face ID or Touch ID
• Apple Platform Security — Sicurezza della biometria
• Android Developers — Show a biometric authentication dialog
• react-native-biometrics — repository e documentazione