Come implementare il Single Sign-On con SAML 2.0 e OpenID Connect tra le applicazioni aziendali e Microsoft Entra ID o Google Workspace

Per implementare il Single Sign-On tra le applicazioni aziendali e Microsoft Entra ID o Google Workspace non si integra ogni applicazione con ogni identity provider: si mette al centro un broker di identità. Le applicazioni parlano un solo protocollo — OpenID Connect — con il broker; il broker parla SAML 2.0 o OIDC con Entra ID e Google Workspace. Il risultato è che una nuova applicazione richiede una configurazione (redirect URI e chiave di progetto) invece di N configurazioni SAML, e che aggiungere un nuovo identity provider non tocca il codice delle applicazioni già in produzione.

OIDC o SAML 2.0: quale usare, e dove

La domanda "SAML o OIDC?" ha risposte diverse a seconda del lato dell'integrazione. Fra le tue applicazioni e il broker conviene quasi sempre OIDC: è JSON, funziona con SPA e app mobile, gestisce il refresh dei token e non richiede parsing e validazione di XML firmato. Fra il broker e l'identity provider aziendale la scelta la detta l'IdP: Entra ID e Google Workspace supportano entrambi, ma molte configurazioni enterprise consolidate (e ADFS on-premise) espongono solo SAML 2.0.

Se ti interessa il confronto teorico fra i protocolli, la trattazione estesa è in OAuth 2.0, OIDC e SAML: differenze e casi d'uso. Qui procediamo con la configurazione.

Passo 1 — Registra l'applicazione come progetto

Ogni applicazione che deleghi il login è un progetto: app web, app mobile e pannello di amministrazione sono tre progetti distinti, ciascuno con la propria chiave crittografica e le proprie policy. È quello che permette di imporre la 2FA obbligatoria sul pannello admin lasciandola opzionale sull'app pubblica, senza duplicare la base utenti.

1. 1Crea il progetto nel tenant e annota il project key (pk_live_…): è l'identificativo pubblico usato nelle chiamate di autenticazione.
2. 2Registra i redirect URI esatti, uno per ambiente. Il confronto è carattere per carattere: https://app.example.com/callback e https://app.example.com/callback/ sono due URI diversi.
3. 3Imposta la durata della sessione e la policy 2FA del progetto (disabilitata, opzionale, obbligatoria).
4. 4Genera una API key (ak_live_…) separata, se il backend dovrà anche fare provisioning: la chiave di progetto serve al login, la API key alle operazioni amministrative.

npm install @loginmaster/sdk

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

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

// Nel callback OIDC: verifica il token a doppia firma (tenant + cloud)
const session = await lm.verifyToken(token);
if (session.valid) {
  const userId = session.subject; // es. sub_9f2a7c
}

Lo stesso vale lato .NET, con il middleware ASP.NET Core; entrambi i quickstart completi sono su Integrazione. Chi non usa TypeScript o .NET integra le stesse operazioni via REST: POST /v1/auth/token e POST /v1/auth/verify.

Passo 2 — Federare Microsoft Entra ID via OpenID Connect

È il percorso da preferire con Entra ID quando non ci sono vincoli storici. Nel portale Entra ID: App registrations → New registration.

1. 1Supported account types: scegli "Accounts in this organizational directory only" per un SSO aziendale chiuso, oppure multitenant se devi accettare più directory clienti.
2. 2Redirect URI (tipo Web): l'endpoint di callback del broker, non quello dell'applicazione finale.
3. 3Certificates & secrets: genera un client secret (o, meglio, registra un certificato) e conservalo nel tenant del broker.
4. 4API permissions: openid, profile, email. Aggiungi User.Read solo se ti serve leggere il profilo Graph; per il solo SSO non è necessario.
5. 5Token configuration: aggiungi il claim dei gruppi se vuoi mappare i gruppi Entra sui ruoli applicativi.

https://login.microsoftonline.com/{tenantId}/v2.0/.well-known/openid-configuration

Da quel documento il broker ricava automaticamente authorization endpoint, token endpoint e jwks_uri, quindi la rotazione delle chiavi di firma di Microsoft non richiede interventi manuali. I claim rilevanti dell'ID token sono:

Passo 3 — Federare Microsoft Entra ID via SAML 2.0

Serve quando l'organizzazione ha già standardizzato su SAML o quando l'IdP è ADFS on-premise. Nel portale: Enterprise applications → New application → Create your own application → Integrate any other application, poi Single sign-on → SAML.

Scarica poi la Federation Metadata XML e caricala sul broker: contiene EntityID dell'IdP, endpoint SSO e certificato di firma, e la sua importazione evita la trascrizione manuale del certificato.

https://login.microsoftonline.com/{tenantId}/federationmetadata/2007-06/federationmetadata.xml

Sul NameID vale la stessa regola del claim oid: imposta user.objectid con formato persistent. Il valore predefinito di Entra ID è spesso l'indirizzo email, ed è la causa numero uno degli account duplicati dopo una riorganizzazione aziendale.

Rotazione del certificato di firma

I certificati SAML di Entra ID hanno una validità predefinita di tre anni e la scadenza interrompe il login di tutti gli utenti nello stesso istante. Due contromisure concrete: configurare le notifiche di scadenza su una casella presidiata, e importare i metadata dell'IdP via URL invece che come file, così il broker rilegge il certificato senza un intervento manuale programmato tre anni prima.

Passo 4 — Federare Google Workspace via OpenID Connect

Google espone un discovery document pubblico e un unico issuer per tutti i domini, quindi la configurazione è più breve di quella di Entra ID — ma con un requisito di sicurezza in più.

https://accounts.google.com/.well-known/openid-configuration

1. 1In Google Cloud Console crea un progetto e, in APIs & Services → Credentials, un OAuth 2.0 Client ID di tipo Web application.
2. 2Authorized redirect URIs: l'endpoint di callback del broker (esatto, https, senza slash finale se non lo usi).
3. 3Configura la OAuth consent screen come Internal se vuoi limitarla al solo dominio Workspace.
4. 4Scope richiesti: openid, email, profile.
5. 5Valida il claim hd (hosted domain) a ogni login lato broker: senza questo controllo, qualunque account Gmail personale che passa dalla stessa schermata di consenso è tecnicamente un login valido.

Passo 5 — Federare Google Workspace via SAML 2.0

Nella Admin console: Apps → Web and mobile apps → Add app → Add custom SAML app. Google mostra i propri metadata (SSO URL, Entity ID, certificato) da caricare sul broker; poi si compilano ACS URL ed Entity ID del Service Provider.

1. 1Copia o scarica i metadata IdP di Google e importali sul broker.
2. 2Service provider details: ACS URL ed Entity ID del broker; Name ID format PERSISTENT e Name ID = Basic Information > Primary email (oppure un attributo custom immutabile, se lo gestisci).
3. 3Attribute mapping: mappa almeno primary email, first name, last name; aggiungi i gruppi se ti servono per i ruoli.
4. 4User access: assegna l'app alle unità organizzative o ai gruppi che devono accedere. Se salti questo passo il login fallisce con app_not_configured_for_user.
5. 5Attendi la propagazione: le modifiche alla Admin console possono richiedere alcuni minuti prima di essere effettive su tutti gli utenti.

Passo 6 — Mappare claim e gruppi sui ruoli applicativi

Il valore vero del SSO federato non è risparmiare una password: è che l'autorizzazione smette di vivere in una tabella locale che nessuno aggiorna. Un utente che cambia reparto cambia gruppo nella directory, e il ruolo applicativo lo segue al login successivo senza ticket all'IT.

Due regole che evitano incidenti: assegna sempre un ruolo di base minimo a chi si autentica ma non corrisponde a nessuna regola (invece di ereditare l'ultimo ruolo noto), e ricalcola i ruoli a ogni login invece che solo alla creazione dell'account. Il secondo punto è ciò che rende effettiva la revoca dei privilegi, non solo quella dell'accesso.

Se i gruppi da propagare sono molti, considera che Entra ID "sovraccarica" il token oltre una certa soglia di gruppi e restituisce un riferimento Graph invece dell'elenco: in quel caso conviene mappare app role espliciti anziché gruppi grezzi.

Passo 7 — Sessione, revoca e deprovisioning

Il SSO è metà del problema; l'altra metà è cosa succede quando l'accesso deve cessare. Con la federazione, disattivare l'account nella directory aziendale interrompe l'emissione di nuove sessioni sui servizi federati: non serve ricordarsi di disattivare l'utente su ogni piattaforma. La finestra residua è la durata dei token già emessi, ed è per questo che va dimensionata consapevolmente.

Per la revoca immediata la leva è il webhook: il broker notifica l'applicazione dell'evento e l'applicazione invalida la propria sessione, senza polling.

POST /hooks/loginmaster HTTP/1.1
X-LoginMaster-Signature: sha256=9f86d081884c...
Content-Type: application/json

{
  "id": "evt_7c1e2f",
  "type": "subject.deactivated",
  "createdAt": "2026-09-10T09:24:00Z",
  "tenant": "https://tenant.example.com",
  "data": { "subjectId": "sub_9f2a7c", "project": "prj_12ab" }
}

Il ciclo di vita completo (creazione, cambio ruolo, sospensione, cancellazione) è trattato in Provisioning e ciclo di vita degli utenti via REST API e SDK.

Il collaudo: nove verifiche prima del rilascio

1. 1Login SP-initiated: dall'applicazione, utente non ancora autenticato presso l'IdP.
2. 2Login IdP-initiated: dal portale Microsoft o Google (solo SAML; con OIDC non esiste e chiederlo è un segnale di requisito mal posto).
3. 3Utente valido ma non assegnato all'applicazione: deve fallire con un messaggio comprensibile, non con una pagina bianca.
4. 4Utente di un dominio esterno: deve essere respinto (verifica del claim hd o del tid).
5. 5Sessione scaduta: rinnovo silenzioso e, se non possibile, ritorno pulito alla schermata di login.
6. 6Logout: verifica se la sessione IdP resta aperta; con SLO parziale l'utente 'esce' e rientra con un clic, e va documentato.
7. 7Account disabilitato nell'IdP: nuovo login rifiutato entro il tempo atteso.
8. 8Orologio disallineato: sposta l'ora di un client di 10 minuti e verifica il messaggio d'errore (SAML fallirà sulle condizioni NotBefore / NotOnOrAfter).
9. 9Rotazione del certificato di firma: simulala in ambiente di test, non scoprirla in produzione.

Errori tipici e come si leggono

Broker gestito, self-hosting o integrazione diretta

Le tre strade sono tutte percorribili, ma hanno profili di costo e di rischio molto diversi. Il confronto onesto è sul lavoro che resta da fare dopo il primo login riuscito.

Il punto che distingue LoginMaster nella riga più in basso non è commerciale ma architetturale: il token restituito all'applicazione porta due firme indipendenti, una del tenant e una del cloud, e un token emesso per il tenant A fallisce la validazione nel contesto del tenant B anche se i due condividono il deployment. Il dettaglio dell'architettura è su Sicurezza, mentre la pagina SSO raccoglie le funzionalità di federazione disponibili. Chi arriva da un'installazione Keycloak trova il percorso completo in Migrare da Keycloak self-hosted a un IAM gestito.

Da dove viene questa guida

LoginMaster è la piattaforma IAM di CDBKR S.r.l., società italiana che sviluppa e gestisce l'infrastruttura di autenticazione per software house, MSP e organizzazioni enterprise europee. Le procedure qui descritte sono quelle che il team applica nei progetti di federazione verso Entra ID e Google Workspace, incluso il caso in cui le due directory convivono nella stessa organizzazione. Un esempio reale di adozione è documentato nei case study; per una valutazione sul proprio scenario il punto di partenza è la pagina contatti.