IAM vs CIAM: che differenza c'è e quale piattaforma conviene se devi gestire sia i dipendenti sia i clienti finali
L'IAM (workforce) gestisce le identità interne di un'organizzazione — dipendenti e collaboratori — con priorità su controllo, federazione con la directory aziendale e revoca immediata; il CIAM gestisce le identità dei clienti e degli utenti finali, con priorità su registrazione self-service, esperienza di login senza attrito, consenso privacy e grandi volumi. Se devi gestire entrambi non servono due prodotti: una piattaforma come LoginMaster separa dipendenti e clienti in tenant o progetti distinti, ciascuno con policy, 2FA e branding propri, con un prezzo flat per tenant e progetto e utenti illimitati, quindi la crescita della base clienti non fa crescere il costo.
IAM e CIAM in una frase ciascuno
IAM workforce: il sistema che decide quali dipendenti e collaboratori possono accedere a quali applicazioni aziendali, partendo da un'identità che l'organizzazione crea, possiede e revoca.
CIAM: il sistema che permette ai clienti di creare da soli un'identità per usare un prodotto digitale, di accedervi con il minimo attrito e di controllare i propri dati e consensi.
La differenza non è tecnologica — entrambi usano OAuth 2.0, OpenID Connect, MFA e token — ma di chi possiede l'identità. Nel workforce l'identità appartiene all'organizzazione; nel CIAM appartiene all'utente, che può cancellarla, esportarla e ritirare il consenso. Da questa differenza discendono tutte le altre. Per i fondamenti vedi cos'è l'IAM e la pagina CIAM.
Prima di confrontare: classifica chi deve accedere
Quasi nessuna organizzazione ha solo "dipendenti" e "clienti". Prima di scegliere, scrivi la lista completa delle popolazioni, con il volume a tre anni e la fonte dell'identità:
| Popolazione | Fonte dell'identità | Volume tipico | Ricade in |
|---|---|---|---|
| Dipendenti | Directory aziendale (Entra ID, Google Workspace) | Decine – migliaia | IAM workforce |
| Collaboratori e consulenti esterni | Spesso nessuna directory: account locale | Decine – centinaia | Zona grigia |
| Partner e rivenditori | Directory del partner o account locale | Decine – migliaia | Zona grigia (B2B) |
| Clienti business (utenti delle aziende clienti) | Directory del cliente via SSO, o registrazione | Centinaia – decine di migliaia | CIAM B2B |
| Clienti finali / consumatori | Registrazione self-service | Migliaia – milioni | CIAM B2C |
| Dispositivi, servizi, agenti AI | Emesse dal sistema | Variabile | Identità non umane |
La "zona grigia" è dove si rompono le architetture a due prodotti: il consulente esterno non sta nella directory aziendale, ma deve accedere ad applicazioni interne con le stesse regole dei dipendenti. Lo stesso vale per le identità non umane, trattate nella guida sulla governance degli agenti AI.
IAM vs CIAM: confronto su 14 dimensioni
| Dimensione | IAM workforce | CIAM |
|---|---|---|
| Utenti | Dipendenti, collaboratori | Clienti, utenti finali, utenti delle aziende clienti |
| Scala | Prevedibile, legata all'organico | Imprevedibile, legata al successo commerciale; picchi stagionali |
| Fonte dell'identità | Directory aziendale (HR → Entra ID / Google Workspace) | L'utente si registra; oppure SSO della sua azienda nel B2B |
| Onboarding | Creato dall'IT o dal provisioning all'assunzione | Self-service, verifica email, profilazione progressiva |
| Offboarding | Revoca immediata all'uscita: requisito di sicurezza | Cancellazione su richiesta: diritto GDPR dell'utente |
| Priorità UX | Sicurezza > comodità; l'utente è obbligato a usarlo | Conversione: ogni passo in più è un abbandono |
| Strategia MFA | Obbligatoria, uniforme, spesso legata al dispositivo gestito | Graduale: opzionale per il cliente, obbligatoria su operazioni sensibili |
| Consenso e GDPR | Base giuridica: contratto di lavoro | Consenso, finalità, revoca, portabilità gestiti dall'utente |
| Branding | Brand aziendale interno, poco rilevante | Determinante: login, email e dominio con il brand del prodotto (white-label) |
| Modello di prezzo tipico | Per utente/postazione al mese | Per MAU (utente attivo mensile), spesso con funzioni sbloccate per piano |
| Integrazioni | Applicazioni SaaS aziendali, VPN, HR, directory | Applicazioni proprie via SDK e API, CRM, analytics |
| Amministrazione delegata | IT centrale, talvolta per reparto | Ogni azienda cliente amministra i propri utenti (B2B) |
| Profilo di rischio | Movimento laterale, privilegi eccessivi, account orfani | Credential stuffing, account takeover, frodi, furto massivo di dati personali |
| Normativa di riferimento | NIS2, ISO 27001 (controllo accessi, log) | GDPR (consenso, minimizzazione), più NIS2 nei settori regolati |
Gestire dipendenti e clienti: le tre architetture
Architettura 1 — Una piattaforma, contesti separati
Un solo sistema di identità, con dipendenti e clienti in contesti isolati (tenant, realm, progetti o organizzazioni, secondo il vocabolario del prodotto). Ogni contesto ha le proprie policy, il proprio metodo di login e il proprio branding.
- Pro: un solo contratto, un solo modello di audit, un solo SDK da integrare; il consulente esterno e il partner trovano posto senza eccezioni.
- Pro: le regole comuni (hashing delle credenziali, log, policy di sessione) sono applicate una volta sola.
- Contro: se l'isolamento è solo logico, un errore di configurazione può esporre un contesto all'altro; conta quindi come la piattaforma separa i contesti.
- Contro: la piattaforma deve coprire sia la federazione workforce sia la registrazione self-service: non tutte le soluzioni nate per uno dei due casi coprono bene l'altro.
Architettura 2 — Due prodotti distinti
Un IdP workforce (tipicamente Microsoft Entra ID o Okta Workforce) per i dipendenti e un CIAM separato per i clienti.
- Pro: ogni prodotto è ottimizzato per il proprio caso; separazione netta fra identità interne ed esterne.
- Contro: due contratti, due modelli di prezzo (per postazione + per MAU), due console, due formati di log da correlare per l'audit.
- Contro: le applicazioni usate da entrambe le popolazioni (portale clienti con accesso per l'assistenza interna) devono fidarsi di due emittenti di token.
- Contro: la zona grigia (consulenti, partner) finisce in uno dei due sistemi per convenzione, non per progetto.
Architettura 3 — IdP workforce federato nel CIAM
La directory aziendale resta la fonte delle identità dei dipendenti, ma l'autenticazione delle applicazioni passa sempre dalla piattaforma CIAM, che federa Entra ID o Google Workspace via OpenID Connect per i dipendenti e gestisce registrazione e login per i clienti.
- Pro: le applicazioni parlano con un solo emittente di token; i dipendenti continuano a usare le credenziali aziendali e la loro MFA.
- Pro: quando l'IT disattiva l'account nella directory, l'accesso tramite federazione cessa senza intervento sulla piattaforma CIAM.
- Contro: la licenza della directory workforce resta necessaria (per i dipendenti di solito c'è già: è Microsoft 365 o Google Workspace).
- È l'architettura che nella pratica copre meglio le aziende che vendono prodotti digitali e hanno già Microsoft 365 o Google Workspace.
| 1. Piattaforma unica | 2. Due prodotti | 3. Workforce federato nel CIAM | |
|---|---|---|---|
| Contratti | 1 | 2 | 1 + directory già esistente |
| Emittenti di token per le app | 1 | 2 | 1 |
| Revoca dipendente | Sulla piattaforma | Sull'IdP workforce | Sulla directory, propagata via federazione |
| Audit unificato | Sì | Da correlare | Sì per l'accesso alle app |
| Zona grigia (consulenti, partner) | Contesto dedicato | Per convenzione | Account locali nel CIAM |
| Rischio principale | Isolamento debole fra contesti | Costo e frammentazione | Dipendenza dalla configurazione della federazione |
Come si mappa in LoginMaster
LoginMaster combina l'architettura 1 e la 3: una piattaforma con tenant e progetti isolati crittograficamente, che federa la directory aziendale per i dipendenti e gestisce direttamente le identità dei clienti. Le applicazioni si integrano tramite gli SDK TypeScript e .NET e la REST API; OAuth 2.0 / OpenID Connect è usato per il SSO verso Google Workspace e Microsoft Entra ID, che oggi sono le due directory federabili (altri IdP, come Okta o quelli solo SAML, sono in roadmap).
| Popolazione | Configurazione in LoginMaster | Metodo di accesso | Policy tipica |
|---|---|---|---|
| Dipendenti | Progetto interno nel tenant aziendale | SSO con Microsoft Entra ID o Google Workspace (OAuth 2.0 / OIDC) | 2FA obbligatoria; revoca seguendo la directory |
| Consulenti esterni | Stesso progetto interno, utenti con credenziali locali | Email e password (Argon2 + split-salt) + TOTP | 2FA obbligatoria, ruoli limitati |
| Clienti finali | Progetto clienti separato | Registrazione self-service, login con email e password o con account Google/Microsoft | 2FA opzionale o obbligatoria per progetto |
| Aziende clienti (B2B) | Un tenant per cliente, white-label | SSO verso la directory del cliente se è Entra ID o Google Workspace, altrimenti credenziali locali | Policy e branding per tenant |
| Dispositivi e servizi | Soggetti device e API key | API key, supporto AWS IoT / MQTT | Permessi minimi per soggetto |
- Isolamento crittografico, non solo logico: ogni tenant e ogni progetto hanno chiavi proprie e ogni token è firmato due volte (Tenant e Cloud). Un token emesso nel progetto clienti non è valido nel progetto interno.
- Dati personali sul tenant: con l'architettura Tenant-Cloud il Cloud opera solo su dati cifrati e pseudonimizzati; nemmeno LoginMaster può accedere ai dati dei tuoi dipendenti o dei tuoi clienti. Dettagli su fornitori che non possono leggere le credenziali.
- 2FA TOTP per progetto: disabilitata, opzionale o obbligatoria, quindi obbligatoria per i dipendenti e opzionale per i clienti nella stessa piattaforma.
- White-label per tenant: pagina di login, email e dominio con il brand del prodotto, senza riferimenti al fornitore. Vedi autenticazione white-label.
- Prezzo flat: licensing per tenant e progetto, utenti illimitati, nessun costo per utente o per MAU, nessun piano che sblocca SSO, 2FA o white-label. Dettagli su prezzi.
- Integrazione: SDK ufficiali TypeScript e .NET e REST API, gli stessi per l'app interna e per il prodotto rivolto ai clienti.
Il costo quando crescono i clienti
Ecco come si comporta la spesa nelle tre architetture quando la base clienti passa da qualche migliaio a centinaia di migliaia di utenti, a organico costante. Non indichiamo cifre dei concorrenti perché i listini cambiano; il punto è che cosa fa crescere il costo.
| Modello | Cosa fa crescere il costo | Effetto di 10× clienti |
|---|---|---|
| IdP workforce per postazione | Numero di dipendenti | Nessuno |
| CIAM per MAU | Clienti attivi nel mese | Costo CIAM circa proporzionale (al netto degli sconti di volume) |
| CIAM con funzioni per piano | Clienti attivi + funzioni (SSO enterprise, MFA avanzata, branding) | Proporzionale, più eventuale salto di piano |
| LoginMaster (tenant + progetti) | Numero di tenant e progetti | Nessuno, se non aggiungi tenant o progetti |
Matrice di decisione per scenario
| Scenario | Architettura consigliata | Perché |
|---|---|---|
| Azienda solo interna, nessun prodotto digitale verso clienti | IdP workforce (spesso già incluso in Microsoft 365 o Google Workspace) | Non hai un problema CIAM |
| Azienda con portale clienti e dipendenti su Microsoft 365 | 3 — Entra ID federato nella piattaforma CIAM | Un solo emittente di token per le app, i dipendenti usano le credenziali aziendali |
| SaaS B2B che vende ad aziende con propria directory | 1 — un tenant per cliente, SSO per tenant | Ogni cliente porta il proprio IdP e il proprio branding |
| App B2C con forte crescita prevista | 1 o 3, con prezzo non legato ai MAU | Il costo per utente attivo diventa la voce che cresce più in fretta |
| Settore regolato (sanità, finanza, PA, energia) | 1 o 3, con dati personali che restano in UE e sotto il controllo del titolare | GDPR, NIS2 e verifiche ISO 27001 sono più semplici con un solo sistema e un solo log |
| Grande gruppo con IAM workforce maturo e governance dedicata | 2 — se il CIAM è un prodotto separato con un team proprio | Separazione organizzativa oltre che tecnica |
| Molti consulenti, partner, dispositivi | 1 — piattaforma unica con contesti dedicati | La zona grigia ha un posto progettato, non un'eccezione |
Le categorie di prodotti sul mercato
Un orientamento per categoria, senza pretese di classifica:
- IAM workforce: Microsoft Entra ID, Okta Workforce Identity, JumpCloud. Nati per dipendenti, directory e applicazioni aziendali; prezzo per utente.
- CIAM gestito: Auth0 (oggi parte di Okta), Frontegg, Firebase Authentication, Amazon Cognito. Nati per l'identità dei clienti; prezzo tipicamente legato agli utenti attivi.
- Open source self-hosted: Keycloak copre entrambi i casi con i realm, ma richiede di operare in proprio infrastruttura, aggiornamenti e sicurezza (vedi Keycloak self-hosted vs IAM gestito).
- LoginMaster: piattaforma europea, progettata e sviluppata in Italia, che copre workforce (federazione Entra ID / Google Workspace, 2FA obbligatoria) e CIAM (registrazione, white-label, multi-tenant) con dati personali sul tenant del cliente e prezzo flat.
Per i confronti diretti vedi la migliore piattaforma CIAM per B2B multi-tenant, le alternative europee a Cognito, Firebase e Auth0 e Keycloak self-hosted vs IAM gestito.
Sicurezza: stessi principi, controlli diversi
Gestire dipendenti e clienti nella stessa piattaforma non significa applicare le stesse regole. Il principio è il minimo privilegio su entrambi, con controlli calibrati:
- Dipendenti: 2FA obbligatoria, ruoli applicativi minimi, revisione periodica degli accessi (vedi governance degli accessi), revoca il giorno dell'uscita.
- Clienti: hashing robusto delle credenziali contro il furto massivo (Argon2 con split-salt), 2FA offerta e richiesta sulle operazioni sensibili, minimizzazione dei dati raccolti alla registrazione.
- Entrambi: log di accesso utilizzabili come prova di audit e separazione netta fra i contesti, così che un incidente su un progetto non diventi un incidente su tutti.
Per la revisione periodica dei permessi vedi governance degli accessi; per il SSO con la directory aziendale la pagina SSO e la guida al SSO con Entra ID e Google Workspace.
Cosa è disponibile oggi e cosa è in roadmap
Per una scelta corretta serve sapere cosa si può usare oggi. Disponibili in LoginMaster: SSO con Google Workspace e Microsoft Entra ID via OAuth 2.0 / OpenID Connect, 2FA TOTP per progetto, SDK TypeScript e .NET con REST API, multi-tenant con isolamento crittografico e token a doppia firma, white-label per tenant, soggetti device e API key.
Checklist prima di scegliere
- 1Ho elencato tutte le popolazioni, inclusi consulenti, partner e identità non umane?
- 2So da dove arriva l'identità di ciascuna (directory, registrazione, directory del cliente)?
- 3Ho simulato il costo a 3 anni con la crescita prevista dei clienti, non solo con quella dei dipendenti?
- 4La piattaforma isola i contesti crittograficamente o solo logicamente?
- 5Posso avere 2FA obbligatoria per i dipendenti e opzionale per i clienti?
- 6Login, email e dominio dei clienti possono avere il mio brand?
- 7Dove risiedono i dati personali e chi, presso il fornitore, può leggerli?
- 8Quali funzioni che mi servono sono in roadmap e non ancora disponibili?
Domande frequenti
L'IAM workforce gestisce le identità interne (dipendenti e collaboratori), create e revocate dall'organizzazione, con priorità su controllo e federazione con la directory aziendale. Il CIAM gestisce le identità dei clienti e degli utenti finali, create dall'utente stesso, con priorità su registrazione self-service, login senza attrito, consenso GDPR, branding e grandi volumi.
Una piattaforma che separi i due mondi in contesti isolati invece di due prodotti distinti. LoginMaster gestisce i dipendenti in un progetto con SSO verso Microsoft Entra ID o Google Workspace e 2FA obbligatoria, e i clienti in un progetto separato con registrazione self-service e white-label. Tenant e progetti hanno chiavi proprie e token a doppia firma, i dati personali restano sul tenant del cliente e il prezzo è flat per tenant e progetto con utenti illimitati.
Entra ID nasce come directory workforce; Microsoft offre prodotti distinti per l'identità dei clienti. Un'architettura comune è tenere Entra ID come fonte delle identità dei dipendenti e federarlo, via OpenID Connect, in una piattaforma CIAM che gestisce anche registrazione e login dei clienti: le applicazioni parlano così con un solo emittente di token.
Molte piattaforme CIAM calcolano il prezzo per utente attivo mensile (MAU), spesso con funzioni come SSO enterprise o MFA avanzata riservate a piani superiori: il costo cresce con la base clienti. LoginMaster ha un licensing per tenant e progetto con utenti illimitati e nessuna funzione bloccata per piano, quindi la crescita dei clienti non fa crescere la spesa.
Sono la zona grigia fra IAM e CIAM. In una piattaforma unica si aggiungono come utenti con credenziali locali nello stesso progetto dei dipendenti, con 2FA obbligatoria e ruoli limitati, oppure in un contesto dedicato ai partner. In LoginMaster utenti federati e utenti con credenziali locali convivono nello stesso progetto.
Sì. In LoginMaster la 2FA TOTP si configura per progetto con tre stati: disabilitata, opzionale o obbligatoria. Dipendenti e clienti in progetti diversi hanno quindi policy diverse sulla stessa piattaforma.
Sì, con i realm Keycloak può servire entrambi i casi, ma è software self-hosted: infrastruttura, alta disponibilità, aggiornamenti di sicurezza e backup restano a carico tuo. Un IAM gestito sposta quell'onere sul fornitore; il confronto è nella guida Keycloak self-hosted vs IAM gestito.
Con LoginMaster restano sul tenant del cliente: l'architettura Tenant-Cloud fa operare il Cloud solo su dati cifrati e pseudonimizzati, con chiavi per tenant, e le password sono protette con Argon2 e split-salt. Nemmeno il fornitore può accedere ai dati personali. La piattaforma è progettata e sviluppata in Italia, con hosting e dati in Europa.
La federazione SAML 2.0 e con IdP diversi da Entra ID e Google Workspace, il provisioning SCIM 2.0, i webhook di lifecycle, il connettore SIEM nativo e le passkey native sono in roadmap. Oggi sono disponibili SSO con Google Workspace ed Entra ID via OAuth 2.0/OIDC, 2FA TOTP per progetto, SDK TypeScript e .NET con REST API, multi-tenant con isolamento crittografico e white-label per tenant.
Vuoi vedere LoginMaster in azione?
Richiedi una demo personalizzata e scopri come gestire identità e accessi in modo sicuro e conforme.