Architetture di login e di sessione per applicazioni mobili native con IdP

Obiettivo e contesto

Questo articolo descrive varianti architetturali pulite per l’autenticazione e la gestione delle sessioni in applicazioni mobili native che utilizzano un Identity Provider (IdP) esterno tramite OAuth 2.0 / OpenID Connect (OIDC).
Obiettivo:

• chiara separazione dei meccanismi
  
• varianti comparabili
  
• base decisionale solida
  

Fondamenti dell’architettura (termini precisi)

2.1 Componenti coinvolti

• App mobile (client pubblico)
  
• Authorization Server / IdP
  
• Resource Server (API)
  

2.2 Artefatti dei token

• Access Token
  • a breve durata (tipicamente: minuti)
    
  • accesso alle API
• Refresh Token
  • a durata più lunga
    
  • serve per rinnovare gli access token
    
  • altamente sensibile

2.3 Due livelli di sessione rigorosamente separati
(A) Sessione IdP

• esiste nel browser di sistema / ASWebAuthenticationSession / Custom Tabs
  
• consente il SSO
  
• non è direttamente controllata dall’app
  
(B) Sessione applicativa

• basata su token memorizzati localmente
  
• completamente sotto il controllo dell’app
  
👉 Questa separazione è centrale per tutte le varianti seguenti.

Dimensioni del design (ortogonali!)

Tutte le architetture significative derivano dalla combinazione di queste dimensioni:

3.1 Dimensione 1: Persistenza della sessione (lato app)
Variante 1: Nessuna persistenza

• token solo in memoria (RAM)
  
• persi dopo il riavvio dell’app
Variante 2: Sessione persistente
• refresh token nel secure storage:
  
  • iOS: Keychain
    
  • Android: Keystore
    
• rinnovo automatico dei token
  

3.2 Dimensione 2: Modello di durata della sessione
Valido per refresh token / sessione:
Durata assoluta
• limite massimo rigido (p. es. 30 giorni)
Timeout di inattività
• scadenza dopo inattività (p. es. 15 min)
Sessione sliding
• estensione con l’utilizzo
  
• tipicamente combinata con:
  
  • rotazione
    
  • durata massima
    
👉 La sessione sliding non è un pattern autonomo, ma un modello di durata.

3.3 Dimensione 3: Rinnovo dei token
Senza refresh token


• l’access token scade → nuovo login necessario
Con refresh token
• silent refresh possibile
Con rotazione
• ogni rinnovo → nuovo refresh token
  
• il token precedente diventa invalido

3.4 Dimensione 4: Protezione dell’accesso lato app
Indipendentemente dall’IdP:

Nessun blocco aggiuntivo

Ri-autenticazione locale

• biometria (Face ID / impronta digitale)
  
• PIN del dispositivo
Opzioni:

• all’avvio dell’app
  
• al ritorno in primo piano
  
• per azioni sensibili (step-up)
  

3.5 Dimensione 5: Livello di sicurezza dei token
Bearer token
• il possesso è sufficiente
Token vincolati al mittente
(p. es. DPoP)
• token legato a una chiave crittografica
  
• protezione contro il furto di token
Vincolati all’hardware
• chiave nel Secure Enclave / TEE
  
• massimo legame al dispositivo
  

3.6 Dimensione 6: Utilizzo della sessione IdP (comportamento SSO)
SSO attivo
• nuovo login possibile senza interazione utente
SSO disattivato / forzato
• p. es. prompt=login
  



Varianti di architettura di riferimento

Combinazioni realistiche e sensate:
Variante A: Sessione effimera (alta sicurezza)
×

Configurazione
• nessuna persistenza
  
• nessun refresh token
  
• access token breve
Proprietà
• la sessione termina alla chiusura dell’app
  
• la sessione IdP può velocizzare il login
Vantaggi
• rischio minimo in caso di perdita del dispositivo
  
• nessuna memorizzazione dei token
Svantaggi
• UX molto scarsa
  
• redirect frequenti
Tipico per
• applicazioni altamente sensibili e specializzate
  


Variante B: Sessione persistente (standard)
×

Configurazione
• refresh token nel secure storage
  
• bearer token
  
• durata assoluta
Proprietà
• «restare connesso»
  
• silent refresh
Vantaggi
• UX molto buona
  
• implementazione standard
Svantaggi
• rischio in caso di esfiltrazione dei token
  
• revoca critica


Variante C: Sessione persistente con sliding + rotazione (best practice)
×

Configurazione
• refresh token + rotazione
  
• sessione sliding + limite assoluto
  
• secure storage
Proprietà
• l’utilizzo attivo prolunga la sessione
  
• i token compromessi vengono rapidamente invalidati
Vantaggi
• ottimo equilibrio tra UX e sicurezza
  
• ampiamente diffusa oggi
Svantaggi
• maggiore complessità
  
• il server deve gestire lo stato


Variante D: Persistenza + ri-autenticazione locale
×

Configurazione
• come variante B o C
  
• in aggiunta
  • biometria / PIN prima dell’accesso
Proprietà
• due livelli di protezione:
  
• possesso (token)
  
• presenza dell’utente
Vantaggi
• sicurezza significativamente maggiore con buona UX
  
• protegge da «shoulder surfing» / dispositivo sbloccato
Svantaggi
• frizione UX
  
• necessaria logica di fallback
Tipico per
• banking
  
• eGovernment


Variante E: Sessione con token vincolati (alta sicurezza moderna)
×

Configurazione
• DPoP o meccanismi simili
  
• chiave nel Secure Enclave / Keystore
  
• spesso combinata con C o D
Proprietà
• il solo token non è sufficiente
  
• vincolo al dispositivo
Vantaggi
• protezione molto elevata contro il furto di token
  
• stato dell’arte
Svantaggi
• complessa
  
• interoperabilità / debugging impegnativi

Confronto delle varianti




Variante	UX	Sicurezza	Complessità	Nota
A Effimera	❌	✅✅	✅	raramente utile
B Persistente	✅	⚠️	⚠️	base
C Sliding + Rotazione	✅	✅	⚠️⚠️	best practice
D + Re-Auth	⚠️/✅	✅✅	⚠️⚠️	per dati sensibili
E Sender-Constrained	✅	🚀	❌	high-end

Temi critici (spesso sottovalutati)

6.1 Semantica del logout

• logout locale → eliminare i token
  
• logout globale → terminare la sessione IdP (browser)
  
• revoca → invalidare i refresh token lato server
  

6.2 Perdita del dispositivo
Domande:

• i token sono protetti?
  
• la biometria è attiva?
  
• esiste una revoca remota?
  

6.3 Comportamento offline

• access token valido → utilizzo offline possibile?
  
• refresh → richiede rete
  

6.4 Multi-dispositivo

• refresh token separati per dispositivo?
  
• invalidazione centralizzata?
  

6.5 Step-up authentication

• ri-autenticazione per azioni critiche
  
• indipendente dalla sessione
  



-Raccomandazioni

• applicazioni standard → variante C
  
• applicazioni sensibili (p. es. eIAM / autorità) → variante D + opzionale E
  
• massima sicurezza → combinazione C + D + E
  



Conclusione

Il punto chiave è:

Non esiste «un unico pattern di login», ma un sistema modulare di decisioni ortogonali.

Un’architettura pulita significa:

• non mescolare le dimensioni
  
• scegliere consapevolmente la combinazione
  
• affrontare esplicitamente i rischi
  

Raccomandazione: architettura di autenticazione e sessione per un’app mobile altamente sensibile

Obiettivo

L’applicazione deve:

• soddisfare elevati requisiti di sicurezza (prevenire abusi in caso di perdita del dispositivo)
  
• rimanere efficiente nell’uso quotidiano
  
• funzionare in condizioni variabili (uso discontinuo, connettività limitata)
  



Architettura raccomandata (combinazione)

2.1 Strategia di sessione
→ Sessione persistente con durata sliding e rotazione
Implementazione
• utilizzo di refresh token
  
• memorizzazione in secure storage della piattaforma
  
• rotazione del refresh token ad ogni rinnovo
  
• combinazione di:
  
  • timeout di inattività (p. es. ore)
    
  • durata assoluta (p. es. giorni)
    
Motivazione
• evita login frequenti durante l’uso
  
• limita l’impatto di compromissione dei token
  
• standard per sistemi moderni e sicuri
  

2.2 Protezione dell’accesso lato app
→ Ri-autenticazione locale obbligatoria
Implementazione
• accesso alla sessione solo dopo:
  
  • biometria (principale)
    
  • PIN del dispositivo (fallback)
    
• applicazione:
  
  • all’avvio
    
  • dopo inattività definita
    
  • per azioni sensibili
    
Motivazione
• protezione contro:
  
  • dispositivi sbloccati non sorvegliati
    
  • dispositivi condivisi
    
• aumento significativo della sicurezza senza re-login completo
  

2.3 Livello di sicurezza dei token
→ Token vincolati al mittente (raccomandato)
Implementazione
• vincolo a una chiave specifica del dispositivo
  
• memorizzazione in:
  
  • Secure Enclave (iOS)
    
  • TEE (Android)
    
Motivazione
• impedisce l’uso su altri dispositivi
  
• riduce il rischio in caso di malware
  

2.4 Integrazione IdP
→ Login tramite browser di sistema (best practice OIDC)
Implementazione
• ASWebAuthenticationSession (iOS)
  
• Custom Tabs (Android)
  
• uso della sessione IdP esistente (SSO)
  
Motivazione
• nessuna gestione di credenziali nell’app
  
• uso del MFA esistente
  

2.5 Strategia di logout e revoca
Implementazione
• logout locale → eliminazione dei token
  
• revoca lato server → invalidazione dei refresh token
  
• opzionale: logout globale tramite IdP
  
Motivazione
• interruzione controllata della sessione in caso di:
  
  • perdita del dispositivo
    
  • cambio di ruolo
    
  • incidenti di sicurezza
    

2.6 Comportamento offline
Raccomandazione
• consentire accesso offline a dati non sensibili già caricati
  
• nessun rinnovo token senza rete
  
• azioni sensibili solo online
  



Livello di sicurezza (valutazione)

La combinazione raccomandata offre:

• alta protezione contro la perdita del dispositivo
  
• alta protezione contro il furto di token
  
• durata della sessione controllata
  
• buona usabilità operativa
  



Alternative scartate

Nessun re-login completo ad ogni utilizzo
• troppa frizione
  
• non praticabile operativamente
Nessuna sessione persistente senza re-auth
• protezione insufficiente in caso di accesso fisico
Nessun uso di soli bearer token
• maggiore rischio di esfiltrazione
  



Misure aggiuntive (opzionali)

• step-up authentication
  
• attestazione del dispositivo
  
• remote session kill
  
• rilevamento root/jailbreak (con cautela)
  



Conclusione

Architettura raccomandata:

Sessione persistente con rotazione
• ri-autenticazione locale
  
• token legati al dispositivo
  

Questa combinazione garantisce un equilibrio robusto tra sicurezza e usabilità ed è adatta per applicazioni con elevati requisiti di protezione.