Single sign-on per la piattaforma di messaggistica con i clienti: guida a OpenID Connect per i team di assistenza

Il single sign-on (SSO) per una piattaforma di messaggistica con i clienti significa che i Suoi operatori accedono con l’account aziendale presso il provider di identità, come Microsoft Entra ID, Okta, Keycloak, AD FS o Google Workspace, invece di usare una password a parte. Lo standard su cui si basa è OpenID Connect (OIDC). Su un’installazione MonoChat on-premise lo configura una sola volta per l’intera installazione, lo limita ai domini e-mail della Sua azienda e può renderlo l’unico modo per accedere.

I team di assistenza hanno un motivo in più per occuparsene. L’account di un operatore apre ogni conversazione WhatsApp, Instagram e Messenger che può vedere: nomi, numeri di telefono, dettagli degli ordini, a volte domande su salute o pagamenti. Quell’account dovrebbe seguire le stesse regole degli altri account aziendali e smettere di funzionare il giorno in cui la persona se ne va.

Perché l’accesso conta per un team di assistenza

Le credenziali rubate o usate in modo improprio restano la via d’ingresso più comune in un’azienda. Il Data Breach Investigations Report 2025 di Verizon, che ha analizzato 12.195 violazioni confermate, ha rilevato che l’abuso di credenziali (22%) e lo sfruttamento di vulnerabilità (20%) sono stati i principali vettori di attacco iniziale.

Una piattaforma di messaggistica con password proprie aggiunge a ogni operatore un set di credenziali in più: una password in più da riutilizzare, un account in più da dimenticare quando qualcuno se ne va, un accesso in più che le Sue regole di autenticazione a più fattori e di accesso condizionale non coprono. Con l’SSO la piattaforma non vede mai la password. Il Suo provider di identità la verifica, applica MFA e criteri di accesso e comunica alla piattaforma chi ha effettuato l’accesso.

Come funziona l’accesso con OpenID Connect

OpenID Connect è un livello di identità costruito sopra OAuth 2.0. Il flusso usato da MonoChat è l’authorization code flow:

1. L’operatore fa clic sul pulsante SSO nella pagina di accesso. MonoChat apre in un pop-up la pagina di accesso del Suo provider di identità.
2. L’operatore accede lì, con la Sua MFA e i Suoi criteri.
3. Il provider di identità rimanda il browser a MonoChat con un codice monouso.
4. Il server MonoChat scambia il codice con un ID token, da server a server. I token non passano mai dal browser.
5. MonoChat controlla l’ID token e fa accedere l’operatore.

L’ID token è, nelle parole della specifica OpenID Connect, «a security token that contains Claims about the Authentication of an End-User» (un token di sicurezza che contiene Claim sull’autenticazione di un utente finale). MonoChat lo accetta solo quando:

• è firmato con una delle chiavi del Suo provider di identità, lette a ogni accesso dal suo discovery document (<issuer>/.well-known/openid-configuration);
• il suo emittente (iss) è il Suo issuer, il suo destinatario (aud) è il client ID di MonoChat e la sua scadenza (exp) non è passata;
• contiene il nonce inviato da MonoChat con la richiesta, che lega il token a questo accesso e impedisce i replay;
• contiene l’indirizzo e-mail della persona e il provider non dichiara quell’indirizzo come non verificato.

La richiesta usa inoltre PKCE (S256) e un valore state; una richiesta di accesso è valida per 10 minuti e può essere usata una sola volta.

Cinque decisioni da prendere prima di attivare l’SSO

Decisione	Opzioni	Che cosa consigliamo a un team di assistenza
Chi può accedere	Ogni dominio, oppure solo i domini e-mail della Sua azienda	Limitare ai Suoi domini
Che cosa succede al primo accesso	Creare l’account, oppure accettare solo le persone invitate	Creare gli account se il Suo provider di identità controlla già chi lavora in azienda
Account esistenti	Collegare l’SSO al primo accesso quando l’e-mail è verificata, oppure dopo un accesso con password	Dipende dal fatto che il Suo provider invii email_verified
Altri metodi di accesso	Mantenere password e accesso con i social, oppure solo SSO	Solo SSO, quando tutti hanno collegato l’SSO
Chi può aprire nuovi workspace	Chiunque abbia un account, oppure solo chi ha il ruolo giusto	Disattivare la creazione libera di workspace in un’installazione aziendale

Metta per iscritto queste scelte prima di cambiare qualsiasi impostazione. Sono le domande che farà il Suo responsabile della sicurezza, e le risposte decidono quali impostazioni Le servono.

Configurare l’SSO su un’installazione MonoChat on-premise

L’SSO si configura per l’intera installazione nelle impostazioni del server, non per singolo workspace. Il riferimento completo è la pagina sul single sign-on nel centro assistenza; qui trova la versione breve.

1. Registrare MonoChat presso il provider di identità

Crei un’applicazione web con un client secret e le assegni:

• il redirect URI https://<your MonoChat domain>/api/oauth/oidc/redirect;
• l’authorization code grant;
• gli scope openid email profile;
• l’autenticazione del client con il secret inviato come HTTP Basic (client_secret_basic).

Verifichi che l’ID token includa il claim email e annoti client ID, client secret e issuer.

2. Copiare l’issuer esattamente

L’issuer è il valore issuer nel discovery document del Suo provider. Forme tipiche:

Provider di identità	Issuer
Microsoft Entra ID	https://login.microsoftonline.com/<tenant id>/v2.0
Okta	https://<your Okta domain>/oauth2/default oppure https://<your Okta domain>
Keycloak	https://<your Keycloak host>/realms/<realm>
AD FS 2016 o successivo	https://<your AD FS host>/adfs
Google Workspace	https://accounts.google.com

Apra <issuer>/.well-known/openid-configuration in un browser e copi il valore carattere per carattere, compresa l’eventuale barra finale. MonoChat rifiuta ogni accesso quando i due valori differiscono, ed è il motivo più comune per cui fallisce il primo test.

3. Aggiungere le impostazioni e riavviare

La parte pubblica (issuer, client ID, percorso di redirect, scope e testo del pulsante) va in public.oauth.oidc; il client secret va in oauth.oidc e resta sul server. Due opzioni qui riportano le Sue decisioni della tabella precedente:

• autoCreateAccounts: true crea l’account MonoChat al primo accesso SSO di una persona, anche quando la registrazione è solo su invito;
• allowedEmailDomains: ["yourcompany.com"] rifiuta ogni indirizzo di un altro dominio. Per Google Workspace, MonoChat controlla il dominio Workspace dell’account (il claim hd) invece dell’indirizzo e-mail, perché un account Google personale può usare un indirizzo di qualsiasi dominio.

Il pulsante riporta «Accedi con SSO» nella lingua di ciascuna persona, oppure l’etichetta che imposta Lei, come «Accedi con Northwind SSO».

4. Rendere l’SSO l’unico metodo, in sicurezza

Quando tutti hanno collegato l’SSO, imposti i metodi di accesso consentiti (public.auth.methods) su ["oidc"]. La pagina di accesso mostra allora solo il pulsante SSO e il server rifiuta l’accesso con password e con i social. I super utenti root possono comunque accedere con la password da /auth/signin?fallback=1, così un provider di identità fuori servizio non blocca mai l’installazione. Per impedire che i nuovi account SSO aprano workspace propri, imposti public.disableTenantCreation su true.

5. Provare quattro accessi

1. Una persona con un account: il pop-up si chiude ed è dentro.
2. Una persona senza account: l’account viene creato, oppure rifiutato se non ha attivato la creazione degli account.
3. Una persona di un altro dominio: rifiutata, se ha limitato i domini.
4. Un accesso con password a SSO-only attivo: rifiutato, mentre l’accesso di emergenza root funziona ancora.

Operatori già presenti: come si collegano gli account

La maggior parte dei team attiva l’SSO con operatori che hanno già un account MonoChat. MonoChat collega l’SSO a un account esistente con lo stesso indirizzo e-mail in uno di due modi:

• Automaticamente, al primo accesso SSO, quando l’installazione consente l’unione e l’ID token dichiara l’indirizzo verificato (email_verified: true).
• Dopo un accesso con password, in tutti gli altri casi: MonoChat chiede alla persona di accedere una volta con la password e collega l’SSO a quel punto. Anche accettare l’invito a un workspace lo collega.

Microsoft Entra ID e AD FS non inviano email_verified. Con questi provider mantenga consentito l’accesso con password finché tutti non hanno collegato l’SSO, oppure inviti di nuovo le persone, prima di passare a solo SSO.

L’SSO è l’identità, i ruoli sono l’accesso

Accedere dà a una persona un account, non l’accesso alle Sue conversazioni. Un account MonoChat può appartenere a più workspace, e le persone accedono prima di sceglierne uno. Una persona vede un workspace solo dopo che questo l’ha invitata e le ha assegnato un ruolo, e il ruolo decide a quali canali, conversazioni e impostazioni arriva. Per impostarli, veda ruoli e permessi nell’inbox del team.

Questa separazione è ciò che vorrà vedere un revisore:

• Nuovo ingresso: il provider di identità crea la persona; un amministratore del workspace la invita e sceglie il ruolo.
• Cambio di mansione: si cambia il ruolo o il gruppo di lavoro in MonoChat; l’accesso non cambia.
• Uscita: si disattiva la persona presso il provider di identità e la si rimuove dal workspace in MonoChat.

Limiti da mettere in conto

• L’app mobile. L’app MonoChat per Android e iOS non offre ancora l’SSO. Se l’SSO è l’unico metodo di accesso, gli operatori non possono accedere dal telefono: tenga un altro metodo per chi usa il mobile oppure pianifichi turni solo da computer.
• Disconnessione. Uscire da MonoChat non disconnette la persona dal provider di identità, e uscire dal provider non la disconnette ancora da MonoChat. Disattivare chi se ne va presso il provider di identità blocca i nuovi accessi; lo rimuova anche dal workspace.
• Rete. I browser delle persone devono raggiungere /api/oauth/oidc/authorize e il percorso di redirect, e il server MonoChat deve raggiungere via HTTPS il discovery document, il token endpoint e il key set del Suo provider. Se limita anche l’installazione per IP, tenga presenti questi percorsi.

Dove si colloca l’SSO in MonoChat

L’SSO si configura nelle impostazioni del server di un’intera installazione, quindi oggi appartiene a MonoChat on-premise: l’opzione Enterprise per i team che eseguono la piattaforma sui propri server, con il proprio LLM e il proprio database vettoriale. La pagina Enterprise illustra l’opzione on-premise, e la pagina sulla sicurezza tratta accesso basato sui ruoli, isolamento dei workspace e certificazioni. Per il lato dati di un progetto di IA, veda la checklist privacy per i chatbot IA.

Per provare prima il prodotto, il piano Basic gratuito su app.monochat.ai Le offre un operatore e un canale.

Fonti

• OpenID Connect Core 1.0, OpenID Foundation, consultato il 4 nov 2026
• Annuncio del Verizon 2025 Data Breach Investigations Report, consultato il 4 nov 2026
• Centro assistenza MonoChat: Single Sign-On for an On-Premise Installation, consultato il 4 nov 2026
• Changelog MonoChat 3.8.43, 2 nov 2026