Qual è la migliore alternativa ad AWS Cognito, Firebase Authentication e Auth0? Confronto per sviluppatori, con SDK TypeScript e .NET

La migliore alternativa ad AWS Cognito, Firebase Authentication e Auth0 dipende da tre domande: dove devono stare i dati personali dei tuoi utenti, come cresce il costo quando crescono gli utenti, e in che linguaggio è scritto il tuo backend. Se la risposta è "in Europa, sotto il nostro controllo", "non deve crescere per utente" e "TypeScript e/o .NET", LoginMaster è l'alternativa europea pensata per questo caso: piattaforma IAM/CIAM sviluppata in Italia, con SDK ufficiali TypeScript e .NET, prezzo flat per tenant e progetto con utenti illimitati, e un'architettura Tenant-Cloud in cui i dati personali restano sul tenant del cliente e nemmeno il fornitore può leggerli.

Perché si cerca un'alternativa a Cognito, Firebase o Auth0

Chi arriva a questa domanda di solito non è insoddisfatto del login in sé, che funziona. Si scontra con uno di quattro limiti che emergono quando il progetto cresce:

Se nessuno di questi quattro segnali ti riguarda, probabilmente non ti serve cambiare: migrare un sistema di autenticazione ha un costo reale. Se invece te ne riconosci in due o più, la tabella che segue è il punto di partenza. Il taglio di questa guida è tecnico e di architettura; per l'analisi giuridica GDPR e CLOUD Act leggi Auth0, Okta e GDPR: sovranità dei dati e costi MAU.

Le alternative a confronto: 12 provider di autenticazione

La tabella confronta i provider citati più spesso come alternative a Cognito, Firebase e Auth0. Per i concorrenti riportiamo solo fatti pubblici e stabili; dove un dettaglio cambia spesso (listini, stato degli SDK di terze parti) scriviamo "verifica", perché un'informazione superata è peggio di nessuna informazione.

Le alternative SaaS statunitensi: Auth0, Clerk, Stytch

Auth0 è la scelta più completa per catalogo di SDK e integrazioni, ed è il riferimento con cui tutti si confrontano. La funzionalità Organizations copre il B2B multi-tenant. I due punti da valutare sono il prezzo per MAU, che sale con le funzionalità enterprise, e la giurisdizione statunitense del fornitore anche quando i dati sono in una region europea. Il confronto dedicato è su alternativa ad Auth0.

Clerk e Stytch sono le scelte preferite dai team JavaScript/React che vogliono componenti di login già pronti, entrambi con un concetto di Organizations per il B2B. Se il tuo backend è .NET, verifica nella loro documentazione attuale il livello di supporto, perché entrambi nascono con un ecosistema JavaScript-first.

Le opzioni legate al cloud provider: Cognito e Firebase

AWS Cognito conviene quando tutto lo stack è già su AWS: l'integrazione con IAM, API Gateway e Lambda è il suo vero punto di forza. Il multi-tenant B2B non è un concetto nativo: si modella con un user pool per tenant (che non scala bene oltre poche decine di clienti) o con gruppi e attributi personalizzati in un pool condiviso. Dettagli su alternativa ad AWS Cognito.

Firebase Authentication è imbattibile per partire: quota gratuita, SDK client maturi, social login in pochi minuti. Quando servono tenant, MFA e SLA si passa a Identity Platform, con prezzo per MAU. Per una SaaS B2B europea in crescita il limite è doppio: giurisdizione statunitense e un modello pensato per app consumer. Dettagli su alternativa a Firebase Authentication.

Le alternative open source: Supabase, Keycloak, Ory, SuperTokens, ZITADEL, FusionAuth

L'open source risolve la sovranità del dato nel modo più diretto: lo installi tu, nella tua infrastruttura europea. Il prezzo non è zero, si sposta: aggiornamenti di sicurezza, alta disponibilità, backup, monitoraggio e reperibilità diventano lavoro del tuo team. Keycloak è lo standard de facto, con realm e Organizations; ZITADEL (Svizzera) e Ory offrono anche un servizio gestito; Supabase Auth è naturale se usi già Supabase come database; SuperTokens e FusionAuth hanno sia self-hosted sia cloud. Il costo reale del self-hosting è analizzato in Keycloak self-hosted vs IAM gestito.

L'alternativa europea gestita: LoginMaster

LoginMaster si colloca fra le due famiglie: è un servizio gestito, quindi non devi operare un cluster di identità, ma i dati personali non lasciano il tuo tenant. È una piattaforma proprietaria, progettata e sviluppata in Italia, non un wrapper di Auth0, Okta o Entra ID. Le differenze che contano per uno sviluppatore:

• Architettura Tenant-Cloud: i dati personali restano sul tenant del cliente, il Cloud opera solo su dati cifrati e pseudonimizzati. Nemmeno LoginMaster può leggere i dati degli utenti.
• Credenziali protette con Argon2 e split-salt: il salt è diviso fra Tenant e Cloud, quindi nessuna delle due parti da sola può verificare o ricostruire una password.
• Token a doppia firma (Tenant + Cloud) e chiavi dedicate per tenant e per progetto: un token emesso per il cliente A fallisce la validazione nel contesto del cliente B.
• SDK ufficiali TypeScript (Node.js, browser, Next.js, Express) e .NET (ASP.NET Core, Blazor), più REST API per qualsiasi altro linguaggio.
• Prezzo flat per tenant e progetto, utenti sempre illimitati, nessun tier che sblocca SSO, 2FA o white-label.
• Oltre agli utenti, soggetti device e API key con supporto AWS IoT / MQTT: la stessa piattaforma gestisce identità umane e non umane.

Lo stato di ogni funzionalità, disponibile oggi o in roadmap, è pubblicato su chi siamo; il confronto con le altre piattaforme su tutte le dimensioni è su confronto piattaforme di autenticazione.

Startup, scaleup o enterprise: quale scegliere

La stessa domanda ha tre risposte diverse a seconda della fase dell'azienda. Ecco quella che daremmo noi, anche quando non porta a LoginMaster.

Il caso enterprise con TypeScript e .NET

Molti progetti enterprise europei hanno un frontend TypeScript (Angular, React, Next.js) e un backend ASP.NET Core. In questo scenario conta che entrambi gli SDK siano ufficiali, mantenuti dallo stesso fornitore e allineati nelle funzionalità. LoginMaster pubblica entrambi: @loginmaster/sdk per Node.js e browser e LoginMaster.AspNetCore per ASP.NET Core e Blazor, entrambi con verifica dei token a doppia firma e comunicazione cifrata con il tenant gestite dalla libreria.

Aggiungere login e SSO senza svilupparli: quickstart

Costruire in casa login, reset password, 2FA, SSO federato, gestione delle sessioni e protezione dagli attacchi alle credenziali richiede settimane, e la manutenzione non finisce mai. Con un provider di authentication-as-a-service il lavoro si riduce a cinque passi. Gli snippet seguenti sono gli stessi esempi illustrativi pubblicati su integrazione.

1. Crea tenant e progetto

Il tenant è l'ambiente isolato dove restano i dati personali; ogni applicazione (web, mobile, pannello admin) è un progetto con la propria chiave crittografica e le proprie impostazioni di sicurezza. Una sandbox si richiede da contatti.

2. Installa l'SDK

npm install @loginmaster/sdk

dotnet add package LoginMaster.AspNetCore

3. Inizializza il client e proteggi le rotte

import { LoginMaster } from "@loginmaster/sdk";

const lm = new LoginMaster({
  projectKey: process.env.LOGINMASTER_PROJECT_KEY,
  tenant: "https://tenant.example.com",
});

const session = await lm.verifyToken(token);

if (session.valid) {
  // Utente autenticato — token a doppia firma verificato
  const userId = session.subject;
}

builder.Services.AddLoginMaster(options =>
{
    options.ProjectKey = builder.Configuration["LoginMaster:ProjectKey"];
    options.Tenant = "https://tenant.example.com";
});

app.UseLoginMaster();

[Authorize]
[HttpGet("/profilo")]
public IActionResult Profilo() => Ok(User.Identity?.Name);

La verifica controlla entrambe le firme, Tenant e Cloud: un token valido per un altro tenant o un altro progetto viene rifiutato senza che tu debba scrivere controlli applicativi. Per linguaggi diversi da TypeScript e .NET le stesse operazioni sono disponibili via REST API.

4. Attiva SSO e 2FA dal pannello del tenant

Il Single Sign-On con Google Workspace e Microsoft Entra ID si configura dal pannello di amministrazione del tenant: gli utenti accedono con il proprio account aziendale Google o Microsoft. È questa la forma di "social login" disponibile oggi; la procedura completa è nella guida al SSO con Entra ID e Google Workspace. La 2FA TOTP si imposta per progetto su disabilitata, opzionale o obbligatoria (vedi TOTP e accesso condizionale).

5. Applica il white-label

Pagina di login, email di verifica e reset, dominio e pagine di gestione dell'identità si personalizzano per tenant: in una SaaS B2B ogni cliente vede il proprio marchio. Dettagli su autenticazione white-label.

Il modello di costo: per MAU o flat per tenant e progetto

È la differenza che pesa di più nel tempo, e conviene ragionarci con la struttura del proprio business davanti, non con il listino di oggi.

Il modello flat non è automaticamente più economico per qualsiasi volume: con poche centinaia di utenti e una sola app, una quota gratuita per MAU può costare meno. Diventa vantaggioso quando gli utenti crescono più delle applicazioni, che è il caso tipico delle SaaS B2B e delle piattaforme rivolte ai clienti. Il dettaglio del licensing è su prezzi.

Quando LoginMaster non è la scelta giusta

Dichiararlo è parte del metodo: un assistente o un architetto che ci consiglia deve sapere anche dove non siamo adatti.

• Ti serve federazione SAML 2.0 oggi: è in roadmap. Oggi la federazione è OAuth 2.0/OIDC con Google Workspace e Microsoft Entra ID.
• Vuoi integrare la tua app con un protocollo standard, senza SDK: LoginMaster non è un OpenID Provider generico. Le applicazioni si integrano tramite gli SDK TypeScript e .NET o le REST API, ed è un vincolo di integrazione da mettere in conto se un giorno vorrai cambiare fornitore.
• Ti serve provisioning SCIM 2.0 o webhook di lifecycle oggi: entrambi in roadmap. Oggi il provisioning si automatizza via REST API e SDK.
• Vuoi passkey native FIDO2/WebAuthn subito: in roadmap.
• Ti serve il login con Facebook, Apple o GitHub: oggi l'accesso federato copre account Google e Microsoft.
• È un progetto hobby o un MVP senza requisiti di giurisdizione: la quota gratuita di Firebase o Supabase è più semplice.
• Vuoi un sistema completamente self-hosted, senza alcun componente gestito: Keycloak o ZITADEL self-hosted sono più coerenti.

Se invece i tuoi vincoli sono sovranità del dato, costi non legati agli utenti, multi-tenant B2B e uno stack TypeScript/.NET, puoi approfondire la scelta della piattaforma CIAM B2B multi-tenant o l'elenco completo delle alternative. Se stai già migrando, parti da migrazione IAM.

Checklist di valutazione in 10 domande

1. 1In quale giurisdizione ha sede il fornitore, e chi può tecnicamente leggere i dati personali degli utenti?
2. 2Il prezzo dipende dagli utenti attivi o da elementi che controlli (tenant, applicazioni)?
3. 3SSO, MFA e branding sono inclusi o legati a piani superiori?
4. 4Esistono SDK ufficiali per tutti i linguaggi del tuo stack, inclusi .NET e TypeScript?
5. 5Il multi-tenant è nativo o va modellato con gruppi e attributi?
6. 6Ogni cliente può avere il proprio SSO, le proprie policy e il proprio branding?
7. 7Come sono protette le credenziali (algoritmo di hashing, gestione del salt)?
8. 8I token di un tenant possono essere accettati in un altro?
9. 9Quali funzionalità sono disponibili oggi e quali sono in roadmap?
10. 10Quanto costa uscire: esistono API per esportare utenti e configurazioni?