Salve, stiamo integrando “Entra con CIE” nella nostra app mobile (Android e iOS) e ci siamo imbattuti in un comportamento che, dopo parecchie prove, ci sembra strutturale e non un difetto della nostra configurazione.
In breve: nella scheda browser interna all’app, il login CIE con le credenziali (codice fiscale + psw) funziona perfettamente. Scegliendo invece il metodo di login con l’app CieID, l’esito dell’autenticazione finisce nel browser esterno e la nostra app non lo riceve mai.
Per chiarezza: nel giro ci sono due browser diversi:
- la scheda del browser dentro l’app (le Custom Tabs): una finestra del browser di sistema che si apre dentro la nostra applicazione. È quella che le librerie standard per il login nelle app native (noi usiamo AppAuth) sono tenute a usare, ed è quella che le linee guida raccomandano al posto di una WebView gestita dall’app;
- il browser esterno: Chrome (o Safari o simili) aperto come applicazione a sé, fuori dalla nostra.
Cosa funziona
Apriamo la pagina di login nella scheda dentro l’app, arriviamo su “Entra con CIE” e scegliamo di autenticarci con le credenziali CIE, digitandole nella pagina web.
Funziona tutto: il login si completa, la scheda prosegue fino in fondo e l’utente resta dentro la nostra app, autenticato. Questo caso è utile perché dimostra che la scheda in‑app non è il problema: configurazione, service provider, sessione, ritorno all’app: funziona tutto.
Cosa si rompe
Stessa app, scheda e pagina. Cambia una sola cosa: invece delle credenziali scegliamo ““Hai l’app CieID” Accedi più velocemente.”. A quel punto:
- si apre l’app CieID;
- terminata l’autenticazione, CieID non riporta l’utente nella scheda dentro la nostra app: apre l’indirizzo di ritorno nel browser esterno, in una scheda nuova;
- la scheda dentro l’app resta freezzata dov’era e non riprende mai; la nostra app torna in primo piano solo se è l’utente a riaprirla a mano ed è freezzata prima del click con ““Hai l’app CieID” Accedi più velocemente.”
Vale la pena descrivere la scena dal punto di vista di chi usa l’app: la persona tocca “Entra con CIE”, inserisce il PIN, appoggia la carta sul telefono, fa tutto giusto e si ritrova in Chrome, fuori dall’app da cui era partita, davanti a una pagina che non c’entra nulla con quello che stava facendo. La nostra app, intanto, non ha ricevuto niente: non sa se l’autenticazione sia andata a buon fine e non può riprendere il flusso. Per l’utente “l’app è rotta”.
Cosa abbiamo scoperto strumentando le prove
Per escludere colpe nostre, abbiamo rifatto tutto con l’app di esempio ufficiale dell’SDK CieID, mettendo a confronto sullo stesso telefono le due modalità: il flusso “vecchio stile” con WebView documentato nel repository, e lo stesso identico indirizzo aperto in una Custom Tab (Android 13, app CieID di preproduzione dal Play Store, Chrome sia come browser sia dietro la Custom Tab: quindi nessun problema di cookie fra i due). Dai log emergono tre cose.
1. Il percorso lato identity provider è identico nei due casi: cambia solo chi lo percorre. Nel flusso WebView è l’app a seguirlo fino in fondo, fino alla pagina (/OpenApp) dove , come da documentazione , è l’app stessa a lanciare CieID aspettandosi una risposta. Nel flusso da browser, invece, a metà del flusso il browser cede la navigazione all’app CieID, e quella pagina ( /OpenApp) non viene mai raggiunta: nessuno, quindi sta "spettando una risposta.
2. Il passaggio da browser a CieID è un meccanismo ufficiale (Android App Links)
Quando nella scheda in-app l’utente clicca "“Hai l’app CieID” Accedi più velocemente., l’Identity Provider esegue un reindirizzamento verso un URL del tipo:
https://ios.preproduzione.idserver.servizicie.interno.gov.it/idp/login/app?...
Su questo dominio è configurato lo standard Android App Links . Quando il browser (Chrome nel nostro caso) prova a caricare questa pagina, Android intercetta l’URL e apre direttamente l’app CieID, trasferendole i parametri di sessione.
Dai log di sistema si vede chiaramente la chiamata.
3. È il canale di ritorno verso l’app originale che manca
Il problema si verifica al termine dell’autenticazione NFC, quando CieID deve restituire l’esito:
- Nel flusso legacy con WebView : È l’app chiamante ad avviare CieID con un’invocazione diretta tra processi (
startActivityForResult). Alla chiusura di CieID, Android restituisce automaticamente il controllo e i dati (RESULT_OK) all’app di partenza. - Nel flusso con Custom Tab / RFC 8252 : CieID non viene aperta direttamente dall’app, ma da Chrome. Quando CieID finisce, non invia un Custom Scheme/Deep Link di ritorno verso l’app chiamante, ma richiede al sistema operativo di aprire un generico URL web di risposta (
https://.../Authn/X509). Non essendoci un legame di contesto con la Custom Tab originale (che opera in una sandbox isolata), Android apre il link in una nuova scheda di Chrome esterno (ChromeTabbedActivity).
Il risultato è che l’utente si ritrova dentro la finestra principale di Chrome, mentre la Custom Tab dentro l’applicazione rimane congelata in background in un contesto isolato, in attesa di un evento di ritorno che non riceverà mai.
Riassumendo: la porta d’ingresso dal browser verso CieID esiste ed è ufficiale; manca invece la porta di ritorno (Deep Link / Custom Scheme verso l’app chiamante). Il flusso sa entrare, ma non sa più uscire.
«E allora si dovrebbe tornare alle WebView?»
Obiezione legittima, e infatti l’abbiamo verificata passo passo: l’integrazione vecchio stile con WebView funziona, anche con la carta. Ma è la strada che le linee guida per le app native (RFC 8252, la best practice per il login OAuth su mobile) vietano esplicitamente, e il motivo non è burocratico: quando il login avviene in una WebView dell’app, l’app può vedere tutto quello che succede lì dentro.
Su iOS
Stessa architettura, stesso esito, con una variante: al termine si finisce su una pagina dell’identity provider che chiede una conferma e poi risponde «Ops, si è verificato un errore». Succede anche con le credenziali di livello 2 scegliendo di passare dall’app, quindi senza NFC e senza carta: è il caso più facile da riprodurre in assoluto, non serve nemmeno avere la CIE sottomano.
Issue correlate
Cercando qui ho trovato Autenticazione CIE su iOS device, del giugno 2023: descrive esattamente la stessa cosa, e la diagnosi sembra già quella giusta : «sembra che, anziché tornare al browser che ha aperto Cie ID, venga aperta una nuova pagina su browser». Quel thread non ha mai ricevuto una risposta ufficiale.
Le domande
Le scrivo senza alcuna polemica , anzi: proprio il fatto che l’ingresso dal browser sia configurato apposta ci fa pensare che questo scenario sia previsto, e che forse manchi soltanto l’ultimo anello.
- Il login avviato dalla scheda in‑app è supportato? Con le credenziali CIE evidentemente sì, visto che funziona. Passando dall’app CieID l’ingresso è ufficiale, ma il ritorno non torna a chi ha aperto il flusso: è previsto che funzioni? È documentato da qualche parte? Per Android, oggi, la documentazione per gli integrators copre soltanto il flusso con WebView.
- È possibile che, al termine, CieID riprenda la scheda da cui il flusso è partito, invece di aprire una finestra nuova nel browser esterno? Nel flusso WebView un ritorno al chiamante esiste già, garantito dal sistema. E per evitare equivoci: non stiamo chiedendo che CieID si fidi di un indirizzo di ritorno qualsiasi indicato da chi chiama , capiamo bene che sarebbe un rischio di sicurezza. Chiediamo l’equivalente di ciò che il flusso vecchio ha già: che la risposta torni al punto di partenza.
- Qualcun altro sta integrando la CIE in un’app nativa con AppAuth o librerie simili? Come l’avete gestita , siete tornati alla WebView, avete rinunciato all’autenticazione tramite app CieID, o avete trovato un’altra strada?
Quando parlo di accesso con credenziali parlo esplicitamente delle credenziali CIE , allego schermata :
Quindi se non fosse chiaro l’errore è quando clicchiamo su “Hai l’app CieID” Accedi più velocemente.