Altre apps che utilizzano SPID, come la “app IO”, richiedono di effettuare il login inserendo password e nome utente per fare login, anche se abbiamo già installato l’applicazione SPID del provider (e.s. PosteId) che permette il login biometrico; Questo, oltre che essere scomodo, presenta numerosi problemi come aumentare il rischio di phishing: l’unica applicazione o sito nel quale dovrei inserire le mie credenziali è quella dello SPID provider, non app terze, come “IO”!!!
Per ovviare a ciò si può aggiungere allo standard SPID delle API Android/iOS specifiche per gestire il login: in Android questo può essere facilmente implementato aggiungendo allo standard SPID l’obbligo di rispondere ad un Intent standardizzato per il login; in iOS non sono troppo esperto ma penso si possano utilizzare le app extensions…
Io penso che in linea di principio non sia un grosso lavoro e che porterebbe molto giovamento sia alla UX che alla sicurezza, cosa ne pensate?
L’autenticazione con utente e password è richiesta solo per il primo livello, il meno sicuro. Già con il secondo non è sufficiente e il meccanismo di OTP, che varia a seconda dei provider, è una soluzione per il problema esposto.
Ciao, la domanda è lecita e la proposta interessante.
Genesi del problema
Tieni però conto che la login SPID nasce nel mondo del web, e quando tu fai login su SPID via browser la password la inserisci nel sito del tuo provider SPID. Quello che fanno le applicazioni come IO è aprire una view del browser che punta al sito (corretto) in https e quindi tu sei al sicuro.
Ma come giustamente fai notare, non si può essere sicuri con nessuna app al mondo che la view non stia in realtà puntando a un sito malevolo. Potremmo fare una demo facile con la login di Google.
La soluzione migliore ancora
Sarebbe quella non di gestire gli Intent, che devono essere gestiti mediante app, per il motivo che sto per illustrare, ma semplicemente il reindirizzamento http come si fa in OAuth. ALT SPID usa SAML 2.0.
Se si potessero usare i redirect accadrebbe questo. Quando scegli lo SPID provider la app di IO lancerebbe un segnale asincrono per l’apertura di una pagina https, es. https://provider.spid/auth/saml. A quel punto, se la app è installata, ti verrà proposto il prompt di sistema, altrimenti si aprirà il browser e potrai vedere l’indirizzo corretto sulla barra di navigazione. Il return url, ovviamente, non è di tipo https ma di tipo uri, quindi quando terminerai la login SPID il sistema passerà il token alla app IO.
Se viceversa l’app non ce l’hai, farai la login via browser, eventualmente con un SMS di verifica
Perché questo?
Perché semplicemente potresti voler fare accesso da un dispositivo diverso, es. un tablet, da quello che ha la app dello spid provider. Oppure semplicemente perché non tutti i provider supportano il flusso con app, o l’utente decide di non installarla, usare l’SMS, usare SPID1, oppure SPID3 con una firma digitale remota (es. Aruba).
Tutto bello?
Eh, insomma… che io sappia la gestione degli URL funziona solo con le chiamate di tipo GET ma SAML si basa sulle POST visto che i token SAML sono documenti XML firmati digitalmente
@nakis in realtà non è una soluzione perché come hai detto tu già ho violato il primo livello. Inoltre dipende come il provider SPID2 ha implementato l’OTP, per esempio quando si usanoSMS è piuttosto facile bucare anche l’OTP (in vari modi… il meno elegante potrebbe essere intercettare l’SMS visto che il protocollo GSM, su cui si basa SMS è stato bucato anni fa, ma ce ne sono altri).
@djechelon come dici tu il problema è che quando mi si apre una webview che ne so io di che sito mi ha aperto (e se veramente è una webview e non una activity fatta per sembrare una webview e ingannarmi?)
La gestione delle URI funziona non solo in Android, ma anche su iOS, Windows, macOS e GNU/Linux…
È una grande idea. Viste le limitazioni di SAML, del fatto che è vecchio e complicato, a questo punto basterebbe aggiungere un endpoint per l’autenticazione che faccia uso di OAuth2 o ancora meglio OIDC a ogni SPID provider.
Questo è la mia proposta: se venisse inserita una soluzione simile nella specifica SPID, per poter essere SPID provider tutti dovrebbero implementare tale funzionalità (sia serverside che app) .
Poi sta all’utente decidere di farne uso o no; come proponevi tu, l’user può decidere cosa fare consapevolmente, informandolo dei rischi. Al contempo le applicazioni che richiedono SPID ne gioverebbero in usabilità.
In base alle linee guida, redatte ai sensi del Codice dell’Amministrazione Digitale (CAD) e adottate da AgID con la Determinazione n. 616/2021, i gestori dell’identità digitale dovranno obbligatoriamente utilizzare OpenID Connect a partire dal 1 maggio 2022. La novità riguarda anche i fornitori pubblici e privati che vogliono erogare i propri servizi online. Nessun cambiamento invece per gli utenti, in quanto le modalità di utilizzo dello SPID rimangono le stesse.
Rispetto allo standard SAML (Security Assertion Markup Language) attualmente usato per lo SPID, AgID evidenzia tre principali vantaggi:
maggiore sicurezza
maggiore facilità di integrazione in sistemi eterogenei (single-page app, web, backend, mobile, IoT)
migliore integrazione di componenti di terze parti in modalità sicura, interoperabile e scalabile
Quindi ci sarà speranza di vederlo in produzione nel Q2/Q3 2022
Una Roadmap ufficiale ancora non esiste, visto anche che i lavori per l’introduzione di OIDC in SPID sono appena iniziati.
Comunque mi pare ovvio che 9300 PA e 80 SP privati non verranno migrati dall’oggi al domani.
Esisterà sicuramente un interregno della durata di vari anni in cui i protocolli SAML e OIDC convivranno in SPID.
Se dovessi scommettere (ma è una pura speculazione personale) direi che, dal momento dell’attivazione degli IDP in OIDC, i due protocolli convivranno per 3-5 anni, a seconda dell’evoluzione dell’interesse verso OIDC.
Non capisco quale sia il problema. Il protocollo (sia OIDC o SAML) viene scelto dal Service Provider (azienda/PA che fa loggare tramite SPID).
Quindi se per “i gestori di SPID” intendi i 7/8 Identity Provider (TIM, Sielte, ecc.) la risposta è sì, devono supportarli tutti e due per chissà quanti anni a venire.
Se intendi i Service Provider di cui sopra no, scegli quello che ti pare e una volta che lo hai implementato non c’è ragione di cambiare (per ora).
Non si capisce perchè l’italia è refrattaria alla modernità.
Esistono gli open standard di FiDO, U2F e FiDO2 che andrebbero implementati su SPiD invece dell’otp che è phisable o degli SMS che sono deprecated da praticamente tutti gli standardization bodies seri.
SPID usa SAML 2.0.