Auth0 o Cognito: regole svizzere sui dati, costi AWS e lavoro che resta

Auth0 di solito vince quando ti serve un'integrazione rapida e una personalizzazione spinta, mentre Amazon Cognito vince quando il tuo stack vive già su AWS e il controllo dei costi è la priorità. Per flussi enterprise con logiche di accesso insolite, l'estendibilità di Auth0 tende a ripagare. In entrambi i casi resti tu il responsabile di una configurazione di sicurezza corretta, e gli obblighi di conformità dipendono da dove e da chi vengono trattati i tuoi dati; padroneggiare questi dettagli è decisivo, come spiegano i passi per le medie imprese per migliorare i digital security fundamentals.

---

In breve:

• Cognito include 10'000 utenti attivi mensili gratuiti nei piani Lite ed Essentials, ma funzioni avanzate, federazione, regioni duplicate e registrazioni dei bot possono far salire il conto.

• Il piano Plus di Cognito aggiunge autenticazione adattiva, rilevamento delle credenziali compromesse e log di sicurezza esportabili; i team esposti al furto di account dovrebbero metterlo a budget fin dall'inizio.

• Le aziende svizzere devono documentare luoghi di trattamento, subresponsabili e garanzie contrattuali; l'hosting in Svizzera da solo non basta a garantire la conformità quando i dati personali sono trattati da provider cloud statunitensi.

• Prima di decidere, verifica se gli hash delle password sono esportabili, testa l'importazione in staging e pianifica una migrazione graduale delle credenziali, per non lasciare i clienti fuori dal loro account.

• Il login gestito di Cognito permette di personalizzare il marchio ma offre meno controllo sul layout; un'interfaccia su misura dà più libertà, ma la sicurezza delle credenziali diventa responsabilità del tuo team.

---

Quale provider è adatto a quale tipo di progetto?

• Ergonomia per gli sviluppatori ed estendibilità: Auth0 è costruito attorno a un'esperienza di sviluppo curata, con una pagina di accesso ospitata che puoi ridisegnare in profondità e hook a runtime che permettono di eseguire codice personalizzato durante accesso e registrazione.

• Integrazione nativa con AWS e profilo di costo: Cognito si collega direttamente a IAM, API Gateway, Lambda e al resto di AWS, e il prezzo è a scaglioni in base agli utenti attivi mensili (MAU), quindi i team che restano dentro AWS vedono spesso costi più bassi e più prevedibili.

• MVP e team piccoli: scegli Auth0 quando vuoi accesso funzionante, login social e MFA in un pomeriggio e prevedi di rifinire i flussi più avanti.

• Prodotti enterprise con tenant complessi: scegli Auth0 quando i clienti chiedono claim personalizzati, provider di identità SAML o OIDC propri e passaggi di onboarding su misura.

• Stack interamente su AWS: scegli Cognito quando i tuoi servizi autorizzano già tramite IAM e vuoi un solo fornitore, una sola fattura e un solo modello di sicurezza.

• App di consumo sensibili ai costi: il piano gratuito di Cognito e il prezzo per MAU sono adatti ad app con molti utenti di basso valore, a patto di tenere d'occhio i componenti aggiuntivi.

• Team con poco tempo per la sicurezza: nessuna delle due opzioni elimina il lavoro di configurazione. Mettilo in conto fin dall'inizio.

Cosa ti permettono davvero di fare le funzioni, e dove ti fermano?

Parti dall'esperienza di accesso. Entrambi i provider offrono una pagina di accesso ospitata: è la strada più rapida e sicura, perché è il provider a gestire l'inserimento delle credenziali. La differenza emerge quando vuoi modificarla. Il login ospitato di Auth0 è altamente personalizzabile, e puoi spingerti oltre con interfacce integrate o completamente su misura tramite i suoi SDK. Il login gestito di Cognito supporta la personalizzazione del marchio, ma accetti limiti più stretti su layout e flusso. Se quei limiti ti stanno stretti, costruisci la tua interfaccia sulle API di Cognito e ti assumi una fetta maggiore della superficie di sicurezza.

L'estendibilità a runtime è il punto in cui i due si allontanano di più. Auth0 ti permette di inserire logica in punti definiti: arricchire un token, bloccare un accesso, chiamare un servizio esterno o collegare account. Cognito offre trigger Lambda per momenti analoghi, come la validazione prima della registrazione e la generazione del token. I trigger funzionano bene se il tuo team ha dimestichezza con Lambda, ma aggiungono latenza e carico operativo, e i flussi complessi a più passaggi possono diventare scomodi rispetto all'approccio più guidato di Auth0.

La copertura dei protocolli è nel complesso simile. Entrambi supportano OAuth 2.0, OpenID Connect, provider social e federazione SAML o OIDC con provider di identità aziendali. Amazon descrive Cognito come comprensivo di passkeys and passwordless sign-in oltre alla federazione, e anche Auth0 supporta WebAuthn e le passkey. L'accesso tra macchine usa in entrambi i casi il flusso client credentials, anche se la personalizzazione dei token per questi flussi è più facile da governare quando controlli tu gli hook.

L'osservabilità conta per le operazioni di sicurezza. Il logging più ricco di Cognito, inclusi i log di sicurezza esportabili, è riservato a un piano di funzioni superiore, di cui parliamo più sotto. Qualunque provider tu scelga, verifica quali eventi puoi inviare al tuo SIEM o alla tua pipeline di log, perché le dashboard nella console di un fornitore raramente bastano per la risposta agli incidenti. Prima di impegnarti, fatti tre domande pratiche: puoi esportare gli eventi di accesso quasi in tempo reale, puoi correlarli con i log della tua applicazione e per quanto tempo il fornitore li conserva?

Come cambiano il costo totale il prezzo per MAU e i piani di funzioni?

Cognito fattura in base agli utenti attivi mensili e al piano di funzioni. Secondo la pagina dei prezzi di AWS, i piani Lite, Essentials e Plus sono fatturati per MAU, con una soglia gratuita di 10'000 MAU per Lite ed Essentials, mentre le funzioni di sicurezza avanzate e i componenti aggiuntivi comportano costi extra. Leggi con attenzione le regole di conteggio dei MAU: in genere un utente diventa fatturabile nel mese in cui si verifica un'azione legata alla sua identità, quindi bot, registrazioni abbandonate e schemi di rinnovo dei token possono gonfiare il conteggio.

Il piano che scegli determina anche quali funzioni puoi usare. Come spiega AWS’s guidance on feature plans, la scelta del piano e le funzioni attivate determinano il costo mensile, e cambiare piano o attivare la sicurezza avanzata modifica sia la fatturazione sia la disponibilità. Tratta il piano come una decisione di architettura, non come una casella da spuntare.

Le sorprese in fattura si concentrano di solito in pochi punti:

• Funzioni di sicurezza avanzate attivate su tutti gli utenti invece che solo su quelli ad alto rischio.

• Accessi federati tramite provider SAML o OIDC, che possono avere un prezzo diverso rispetto agli utenti nativi.

• Architetture multi-regione in cui dati utente e traffico vengono duplicati.

• Moduli di registrazione pubblici che attirano iscrizioni automatiche.

Per la stima, costruisci un piccolo modello prima del lancio. Usa valori indicativi, non dati di mercato. Stima gli utenti mensili attesi, tieni conto della soglia gratuita descritta sopra, poi calcola gli utenti rimanenti alla tariffa per MAU del piano scelto. Aggiungi il costo di ogni componente aggiuntivo che prevedi di attivare e rifai la stima in scenari di traffico più basso e più alto. Ripeti lo stesso esercizio per Auth0 con la sua pagina dei prezzi attuale e confronta le curve, non un singolo punto. L'opzione più economica con pochi utenti spesso non è la più economica quando gli utenti crescono.

Com'è fatta la sicurezza e quali sono le tue responsabilità legali?

Parti da chi fa cosa. La documentazione di sicurezza di AWS per Cognito inquadra così il modello di responsabilità condivisa: il provider fornisce gli strumenti di identità, ma il cliente o l'architetto è responsabile di configurare correttamente i flussi di autenticazione e le impostazioni di sicurezza. Nella pratica Auth0 funziona allo stesso modo. Una piattaforma solida con una configurazione debole resta un sistema debole.

Anche le funzioni di sicurezza variano in base al piano. Il piano Plus aggiunge autenticazione adattiva, rilevamento delle credenziali compromesse e log di sicurezza esportabili, che insieme permettono controlli basati sul rischio e analisi forensi migliori. Se il tuo modello di minaccia comprende il credential stuffing o il furto di account, metti a budget le funzioni di livello Plus dal primo giorno, invece di scoprire la lacuna dopo un incidente.

Per le aziende svizzere, il lato legale richiede la stessa disciplina. Con la nuova legge federale sulla protezione dei dati (nLPD), guidance from PrivacyBee spiega che ospitare i dati in Svizzera non garantisce di per sé la conformità se usi provider cloud statunitensi. Nel registro dei trattamenti devi indicare il responsabile del trattamento, le categorie di trattamento e il Paese in cui avviene, e assicurarti che il contratto di trattamento dei dati (DPA) copra i requisiti specifici svizzeri, come la responsabilità dei dirigenti. L'Incaricato federale della protezione dei dati e della trasparenza (IFPDT) aggiunge che i titolari del trattamento devono verificare processing locations, sub-processors and contractual safeguards prima di esternalizzare a un provider cloud.

Controlli da pretendere da qualsiasi fornitore di identità:

• Log esportabili e una politica di conservazione chiara.

• Un elenco aggiornato dei subresponsabili con le relative sedi.

• Opzioni di gestione delle chiavi, come l'uso di chiavi proprie, dove disponibili.

• Un DPA abbastanza specifico da reggere a una verifica, non un modello generico.

Se non sei sicuro che un trasferimento verso un determinato Paese sia ammissibile, consulta la guida dell'IFPDT sui trasferimenti di dati all'estero e un avvocato qualificato.

Quanta frizione devi aspettarti il primo giorno?

La velocità di realizzazione dipende meno dagli elenchi di funzioni che dalla rapidità con cui un nuovo sviluppatore ottiene un accesso funzionante. Auth0 è noto per l'ampia copertura di SDK su web, mobile e framework backend, per le guide rapide dedicate agli stack più comuni e per una console che rende visibile la configurazione dei tenant. Il punto forte di Cognito è l'integrazione stretta con AWS, compresa la configurazione rapida di registrazione, accesso e federazione, ma console e documentazione danno per scontato che tu ragioni già in termini AWS. I team che padroneggiano IAM e CloudFormation o Terraform vanno veloci. I team nuovi ad AWS perdono spesso giorni dietro a policy e collegamenti tra risorse.

La scelta tra accesso ospitato e integrato condiziona sia il marchio sia il rischio. Un accesso ospitato mantiene la gestione delle credenziali sul dominio del provider e riduce la tua superficie d'attacco, al prezzo di un po' di controllo visivo. Un'interfaccia integrata o su misura ti dà il controllo al pixel, ma ti rende responsabile della protezione del modulo, della gestione sicura degli errori e dell'aggiornamento degli SDK.

Documentazione e comunità moltiplicano la velocità. L'ecosistema più ampio di tutorial di terze parti di Auth0 aiuta quando incontri un caso limite, mentre le domande su Cognito si risolvono spesso con la documentazione AWS, i forum e il tuo piano di supporto. Valutalo in base a quanta documentazione di riferimento il tuo team è disposto a leggere.

Infine, pianifica per tempo la gestione degli ambienti. I segreti dei client applicativi devono stare in un gestore di segreti, non nei repository. Tieni tenant o user pool separati per sviluppo, staging e produzione, e programma la rotazione di chiavi e segreti in modo che diventi routine e non un'emergenza.

Cosa dovrà comunque gestire il tuo team dopo il lancio?

Nessuno dei due prodotti trasforma l'identità in un servizio da impostare e dimenticare. Al tuo team resta il ciclo di vita degli utenti: creazione, disattivazione, recupero dell'account e richieste di assistenza. Sono tue anche la sorveglianza delle frodi, a meno che tu non paghi per un rilevamento gestito, e la politica MFA: chi deve registrarsi, quali fattori sono ammessi e cosa succede quando qualcuno perde un dispositivo.

La maggior parte degli incidenti nasce dalla configurazione, non da difetti del fornitore. Le indicazioni di AWS sulla gestione della sicurezza ricordano che consentire la registrazione pubblica o usare client pubblici aumenta l'esposizione, e che pianificare la sicurezza dello user pool aiuta a evitare abusi e costi imprevisti. Gli stessi errori producono sia violazioni sia fatture. Tra gli sbagli frequenti ci sono anche durate dei token molto più lunghe di quanto serva alla sessione, URL di reindirizzamento troppo ampi e credenziali amministrative condivise tra colleghi.

Le buone abitudini operative sono quasi sempre noiose. Separa gli ambienti, così uno script di test non tocca mai gli utenti di produzione. Imposta avvisi sulla crescita dei MAU, così un'ondata di bot arriva come notifica e non come fattura. Rilascia i cambiamenti, per esempio nuovi obblighi di MFA, a tappe: prima gli utenti interni, poi una piccola percentuale di clienti, infine tutti. Rivedi i log di identità con cadenza regolare, non solo quando qualcosa si rompe, e documenta chi ha accesso alla console.

Quanto è difficile cambiare in futuro?

Il vincolo con il fornitore raramente nasce dalla tabella degli utenti. Nasce da tutto quello che le sta attorno. Gli attributi del profilo sono di solito esportabili da entrambi i provider, ma il nodo sono gli hash delle password: alcune piattaforme non li esportano affatto, il che obbliga a una campagna di reimpostazione delle password oppure a una migrazione progressiva che ricalcola gli hash man mano che gli utenti accedono. Verifica che cosa ogni fornitore esporta e che cosa no prima di impegnarti, non quando vuoi andartene.

Claim personalizzati, formati di token su misura e logica di hook o trigger stringono ancora di più il legame. Ogni servizio a valle che legge un claim personalizzato diventa parte della migrazione. Le connessioni SSO esterne aggiungono un altro livello, perché il provider di identità di ogni cliente aziendale potrebbe dover essere riconfigurato.

Un piano di migrazione sensato ha tre parti:

• Verificare l'esportazione e fare un'importazione di prova in un tenant di staging.

• Usare una migrazione progressiva o a fasi per le credenziali, così nessun utente resta fuori.

• Scrivere un piano di rientro che tenga attivo il vecchio provider finché il traffico non si è dimostrato stabile.

Tieni lo schema dei claim documentato e ridotto all'essenziale: così riduci il costo di qualsiasi trasloco futuro.

Come eviti sorprese in fattura?

Il controllo dei costi si riduce quasi sempre a contare meno utenti che non contano e ad attivare le funzioni costose solo dove rendono.

• Blocca i MAU fasulli. Aggiungi limiti di frequenza, CAPTCHA e rilevamento delle registrazioni sospette sui moduli pubblici, così i bot non diventano mai utenti fatturabili.

• Attiva le funzioni avanzate in modo selettivo. Abilita autenticazione adattiva e componenti simili per i segmenti ad alto rischio o per gli account amministrativi, poi misura l'impatto sui costi prima di estenderli.

• Gestisci i token in cache con criterio. Riutilizza i token validi e usa i flussi di rinnovo in modo consapevole, così la tua app non genera eventi di identità inutili.

• Avvisa prima del salto. Imposta allarmi di fatturazione e notifiche automatiche quando il conteggio dei MAU si avvicina alla soglia di un piano.

Quando conviene farsi aiutare da figure senior?

Scegliere tra Auth0 e Cognito è la parte facile. Il lavoro costoso è l'integrazione: far passare i token attraverso i tuoi servizi, migrare utenti attivi senza lasciarli fuori e documentare i trattamenti per una verifica di conformità svizzera. Il nostro è uno studio piccolo, in cui gli ingegneri senior restano coinvolti dalla prima conversazione fino alla consegna: così i requisiti non vengono riscritti a metà progetto e il sapere acquisito non se ne va.

Possiamo aiutarti con:

• Realizzare accesso, SSO e MFA in app e piattaforme web o mobile.

• Pianificare ed eseguire migrazioni di sistema tra provider di identità.

• Sessioni di consulenza su architettura, rischio fornitore e scelte di integrazione attente alla nLPD.

• Supporto e monitoraggio continui una volta che l'autenticazione è attiva.

Scrivici quando hai davanti una migrazione complessa, ti serve un parere senior sull'architettura di identità o vuoi una seconda opinione prima di firmare il DPA di un fornitore. Guarda la nostra pagina con prezzi e servizi per trovare la formula adatta e raccontaci che cosa stai costruendo.

Questo articolo contiene informazioni generali e non sostituisce il parere di un avvocato qualificato. Prima di agire, consulta un professionista legale qualificato sulla tua situazione specifica.

Domande frequenti

Chi sono i principali concorrenti di Auth0?

Le principali alternative ad Auth0 sono altre piattaforme di identità gestite, tra cui Amazon Cognito, Firebase Authentication e servizi simili. Quale sia il concorrente più valido dipende dal tuo stack: Cognito è adatto ai team centrati su AWS, mentre Firebase è adatto a chi sviluppa già con gli strumenti di Google.

Quali sono gli svantaggi di usare Amazon Cognito?

Prima di scegliere Cognito, verifica tre cose: fino a che punto si può personalizzare il suo login ospitato, quanta dimestichezza ha il tuo team con AWS e i trigger Lambda e quali funzioni si trovano nei piani più cari. Pianificarle per tempo evita sorprese su costi e perimetro.

Di chi è Auth0?

Auth0 è una piattaforma di identità commerciale, acquisita da Okta. Controlla nel suo DPA le informazioni societarie e l'elenco aggiornato dei subresponsabili, perché proprietà e luoghi di hosting contano per la documentazione di conformità.

Che differenza c'è tra OAuth e Auth0?

OAuth è un protocollo aperto di autorizzazione, uno standard per concedere accesso limitato alle risorse. Auth0 è un prodotto commerciale che implementa OAuth 2.0, OpenID Connect e altri standard come servizio gestito.