Come gestire l'autenticazione multi-tenant per una SaaS B2B, con login white-label per ogni cliente

L'autenticazione multi-tenant di una SaaS B2B si gestisce modellando ogni cliente aziendale come un tenant isolato, con la propria base utenti, le proprie policy di sicurezza, la propria federazione SSO verso l'identity provider del cliente e il proprio branding sulle pagine di login. Le decisioni che contano sono sei, si prendono prima di scrivere codice, e la più costosa da cambiare in seguito è la prima: se un utente è un'entità unica della piattaforma che appartiene a più tenant, o se ogni tenant ha una base utenti separata.

Passo 1 — Il modello di identità: la decisione irreversibile

La domanda concreta è questa: se Mario lavora per il cliente A e viene invitato anche dal cliente B con lo stesso indirizzo email, sono una persona o due?

La scelta va fatta con davanti il modello di vendita, non il modello dati: se vendi a grandi aziende che portano i propri dipendenti, la base separata per tenant è quasi sempre corretta; se il tuo prodotto è usato da agenzie e consulenti che lavorano per più clienti, la separazione rigida diventa una lamentela ricorrente al terzo mese.

Passo 2 — Come si risolve il tenant al login

Prima di autenticare devi sapere in quale contesto stai autenticando: serve a mostrare il branding giusto, a scegliere la policy giusta e a indirizzare verso l'identity provider giusto.

Nella pratica le SaaS mature ne combinano due: sottodominio o dominio personalizzato per il branding, e home realm discovery sul dominio email per indirizzare gli utenti federati all'IdP corretto.

Passo 3 — SSO federato per singolo cliente

Il primo cliente enterprise che firma un contratto significativo chiede il SSO con il proprio Entra ID. Il secondo usa Google Workspace. Il terzo ha Okta e un requisito SAML 2.0. Se la federazione è configurata a livello globale invece che per tenant, ogni nuovo cliente diventa un progetto di sviluppo.

• La configurazione dell'identity provider (client ID, secret o certificato, metadata, mappatura dei claim) deve appartenere al tenant.
• La mappatura gruppi → ruoli è diversa per cliente: 'GRP-ADMIN' in Acme e 'amministratori@beta.com' in Beta devono poter puntare allo stesso ruolo applicativo.
• Serve la convivenza fra utenti federati e utenti con credenziali locali nello stesso tenant: quasi ogni cliente ha almeno un consulente esterno fuori dalla propria directory.
• Il deprovisioning segue la directory del cliente: quando l'IdP disattiva l'utente, l'accesso alla tua SaaS cessa senza un ticket verso il tuo supporto.

La procedura completa di federazione verso Entra ID e Google Workspace, con endpoint, claim ed errori tipici, è nella guida dedicata al SSO con SAML 2.0 e OIDC.

Passo 4 — White-label: cosa deve essere personalizzabile davvero

"White-label" usato come sinonimo di "puoi caricare il logo" è la causa più frequente di rinegoziazione con il cliente enterprise. L'elenco di ciò che l'utente finale vede, e che quindi deve poter essere del cliente, è più lungo di quanto sembri.

In LoginMaster nessun riferimento al fornitore compare nell'esperienza utente di produzione, e la personalizzazione si estende a template email, dominio e pagine di gestione identità, con template diversi per lingua e per tipologia di utente. Il dettaglio è su autenticazione white-label.

Passo 5 — Isolamento: logico o crittografico

Quasi tutte le piattaforme dichiarano l'isolamento fra tenant. La domanda che discrimina è: l'isolamento è garantito da un controllo applicativo — una clausola WHERE tenant_id = ? e un claim nel token — o da una proprietà crittografica?

La differenza si vede in un solo scenario, ma è quello che conta: un bug in una query, un claim non verificato, un parametro manipolabile. Con l'isolamento applicativo, quel bug è un data breach fra clienti. Con l'isolamento crittografico, la validazione fallisce strutturalmente perché il token non è firmato con le chiavi di quel tenant.

POST /v1/auth/verify HTTP/1.1
Host: api.loginmaster.it
X-Project-Key: pk_live_••••••••
Content-Type: application/json

{ "token": "lm2f.eyJhbGciOiJFZERTQS..." }

HTTP/1.1 200 OK
{
  "valid": true,
  "subject": "sub_9f2a7c",
  "tenant": "https://acme.example.com",
  "signatures": { "tenant": "verified", "cloud": "verified" }
}

Ogni tenant ha la propria identità crittografica e ogni progetto la propria chiave: un token emesso per il tenant Acme, presentato nel contesto del tenant Beta, non fallisce un controllo — fallisce la verifica della firma. È la stessa proprietà che rende sostenibile ospitare clienti concorrenti fra loro sulla stessa piattaforma, che è la norma in una SaaS verticale.

Passo 6 — Onboarding di un nuovo cliente via API

Se creare un tenant richiede l'intervento di una persona, il costo marginale di un cliente non scende mai. L'onboarding deve essere una sequenza di chiamate API eseguibile dal tuo backoffice o da un flusso self-service.

1. 1Crea il tenant e imposta le policy di base (durata sessione, requisiti password, tipi di secondo fattore ammessi, domini email autorizzati).
2. 2Registra i progetti: applicazione web, app mobile, eventuale pannello di amministrazione del cliente, ciascuno con la propria policy 2FA.
3. 3Applica il branding: logo, palette, template email, lingua predefinita.
4. 4Configura la federazione, se il cliente porta il proprio identity provider.
5. 5Effettua il provisioning degli utenti iniziali e sottoscrivi i webhook per sincronizzare lo stato applicativo.

POST /v1/projects/prj_12ab/subjects HTTP/1.1
Host: api.loginmaster.it
Authorization: Bearer ak_live_••••••••
Content-Type: application/json

{
  "type": "user",
  "externalId": "acme-4821",
  "roles": ["member"]
}

Il ciclo di vita completo, inclusi cambio ruolo e disattivazione, è in Provisioning e ciclo di vita degli utenti via REST API e SDK.

Costruire, self-hosting o piattaforma: il confronto

Le opzioni reali per una SaaS B2B sono quattro. Nessuna è sbagliata in assoluto: cambiano il momento in cui il costo si manifesta e chi lo paga.

Il punto sul pricing, che in B2B è architetturale

In una SaaS B2B il numero di utenti finali non lo decidi tu: lo decide il tuo cliente. Un modello di autenticazione a costo per utente attivo significa che un contratto vinto con un cliente da 30.000 dipendenti porta con sé un costo variabile che erode il margine di quel contratto esattamente quando dovrebbe migliorarlo. LoginMaster fattura per tenant e per progetto, con utenti sempre illimitati e inclusi: il costo dell'autenticazione resta prevedibile mentre i tuoi clienti crescono. Il modello è descritto su prezzi.

Serve una CIAM o una IAM?

Chi valuta piattaforme per una SaaS B2B multi-tenant incontra entrambe le sigle. IAM in senso stretto governa le identità workforce: dipendenti, SSO aziendale, ciclo di vita, accessi interni. CIAM governa le identità dei clienti: registrazione self-service, login white-label, volumi molto più alti e attenzione all'esperienza. Una SaaS B2B ha bisogno di entrambe, perché i suoi utenti sono dipendenti di aziende clienti: identità con requisiti CIAM di scala e branding, ma governate dalle policy workforce del cliente.

È il motivo per cui la stessa piattaforma deve coprire i due mondi nello stesso tenant, con policy e branding distinti per tipologia di utente: le pagine CIAM e IAM per SaaS B2B trattano i due lati.

Da dove viene questa guida

LoginMaster è la piattaforma IAM di CDBKR S.r.l., società italiana che fornisce l'infrastruttura di autenticazione a software house e MSP che rivendono il proprio prodotto a clienti aziendali. Il concetto di tenant, l'isolamento crittografico e il white-label descritti qui sono i vincoli architetturali su cui il prodotto è costruito, non funzionalità aggiunte in un secondo momento: Sicurezza ne descrive il dettaglio, i case study mostrano un'adozione reale e il programma partner il modello per chi rivende. Per discutere il proprio scenario: contatti.