Articolo di Daniel Marella – Full-stack Developer in AzzurroDigitale
Ti è mai capitato di dover ricordare mille username e password per accedere agli strumenti di lavoro?
Con il Single Sign-On (SSO) questo problema sparisce: ti autentichi una sola volta e accedi automaticamente a tutte le applicazioni e i servizi collegati, senza dover inserire le credenziali a ogni cambio di strumento.
In pratica: un solo login e via, tutto il resto si apre da sé.
Noi di AzzurroDigitale abbiamo implementato il Single Sign-On in diversi progetti, come l’integrazione di Wepladoo per Staff International, utilizzando lo standard OpenID Connect (OIDC1).
I risultati? Confermano pienamente i vantaggi concreti dell’SSO, sia per gli utenti finali che per le aziende.
Benefici dell’SSO per l’utente finale
✅ Accesso semplificato
Un solo login per accedere a tutti i sistemi autorizzati = niente più credenziali multiple da ricordare.
🚀 Aumento della produttività
Accesso istantaneo agli strumenti di lavoro, anche da remoto e su dispositivi diversi.
Passaggio fluido tra app e meno distrazioni: tutto contribuisce a una giornata di lavoro più efficiente.
Passare da un’app all’altra (CRM, ERP, tool di project management…) è immediato e senza continui login/logout, migliorando il flusso di lavoro quotidiano.
🔐 Sicurezza personale più alta
Meno password = meno errori e rischi. L’esperienza rimane fluida senza compromettere la protezione dei dati.
Benefici dell’SSO per l’azienda
🧾 Compliance semplificata
Accessi centralizzati, tracciabili e gestiti da un’unica console. L’SSO semplifica la conformità a normative come GDPR, ISO, HIPAA2, garantendo controllo e auditabilità.
🔐 Sicurezza rafforzata
Meno credenziali da gestire = meno vulnerabilità. L’SSO riduce la superficie di attacco e si integra facilmente con MFA3, rafforzando la protezione degli accessi.
📉 Meno errori e ticket IT
Meno password dimenticate, meno richieste di supporto. Gli utenti sono più autonomi e l’IT può dedicarsi a progetti strategici invece che a gestire ticket ripetitivi.
🔄 Onboarding e offboarding più rapidi
Con l’SSO integrato alla gestione utenti, i nuovi dipendenti hanno accesso immediato agli strumenti di lavoro e, in caso di uscita, gli account vengono disattivati in modo centralizzato e sicuro.
📊 Migliore controllo e governance
Monitoraggio continuo e visibilità completa su chi accede a cosa, quando e da dove. Ideale per rafforzare la sicurezza e prevenire comportamenti anomali.
⚙️ Facile integrazione e scalabilità
Basato su standard aperti come per esempio: OpenID Connect (OIDC), l’SSO si integra con qualsiasi ecosistema IT, facilitando la crescita e l’adozione di nuove soluzioni digitali.
Come funziona l’SSO?
Con il Single Sign-On, una volta effettuato il login iniziale, non dovrai più inserire username e password per ogni applicazione. Più precisamente:
- L’azienda utilizza un Identity Provider (IdP4), il sistema che gestisce e verifica gli accessi degli utenti.
L’IdP è il “guardiano” centrale della sicurezza degli accessi aziendali: autentica gli utenti quando provano a entrare, gestisce in modo sicuro le credenziali (spesso con supporto per l’autenticazione a più fattori, MFA) e rilascia i token digitali necessari per accedere alle applicazioni senza dover inserire username e password a ogni login. - Le applicazioni aziendali si “fidano” del token emesso dall’IdP
- Tutto avviene tramite protocolli standard (es. SAML5, OAuth2, OpenID Connect)
Nel nostro caso, l’implementazione dell’SSO si basa su OpenID Connect (OIDC), uno standard moderno progettato per gestire l’autenticazione in modo sicuro, flessibile e adatto a sistemi cloud e API-driven. Si tratta di un protocollo di autenticazione, pensato per identificare in modo sicuro gli utenti e permettere alle applicazioni di fidarsi di questa identità, senza dover gestire direttamente le password.
OpenID Connect (OIDC), in breve
Lo standard che abbiamo adottato è OpenID Connect, perfetto per ambienti cloud e API-driven.
Come funziona:
- L’utente prova ad accedere a un’app aziendale.
- L’app lo reindirizza all’IdP (Google, Azure AD, Okta…).
- L’utente inserisce le credenziali e, se previsto, completa l’MFA.
- L’IdP genera:
- ID Token → contiene l’identità dell’utente.
- Access Token (opzionale) → per accedere a risorse protette.
- L’app valida il token e concede l’accesso.
Un ID Token contiene una serie di informazioni fondamentali sull’utente, come l’indirizzo email, il nome, un identificativo univoco, eventuali ruoli o permessi assegnati e la data di scadenza del token stesso. Tutti questi dati sono firmati digitalmente, in modo che le applicazioni possano verificarne l’autenticità e fidarsi del loro contenuto senza dover contattare nuovamente l’Identity Provider.
Scegliere OpenID Connect significa optare per una soluzione pensata per gli ambienti moderni: è perfetta per web app, applicazioni mobile e API, si integra facilmente in architetture distribuite e cloud-native, garantisce sicurezza grazie a token firmati, temporanei e compatibili con l’autenticazione a più fattori, ed è semplice da implementare anche con framework e provider già esistenti.
👉 Non avete ancora un Identity Provider (IDP)?
Nessun problema: AzzurroDigitale può supportarvi nell’intero processo di integrazione, guidandovi passo dopo passo verso una soluzione SSO completa, sicura e su misura per la vostra realtà.
Deep Tech per gli addetti ai lavori
Dentro il motore dell’SSO (con OpenID Connect) – Wepladoo per StaffInternational
L’SSO è molto più di una semplice esperienza utente: è un’architettura complessa di orchestrazione dell’identità che si basa su protocolli standardizzati, scambio sicuro di token firmati digitalmente e comunicazioni affidabili tra sistemi distribuiti.
La tecnologia chiave nell’integrazione dell’SSO per StaffInternational con Wepladoo è OpenID Connect (OIDC), un protocollo di identità che abilita flussi di autenticazione sicuri e standardizzati per la gestione degli utenti.
📚 I componenti fondamentali del sistema
| Componente | Ruolo |
|---|---|
| User Agent | Browser o app mobile usata dall’utente per interagire con le applicazioni |
| Client | Applicazione che richiede l’accesso alle risorse protette |
| Authorization Server / Identity Provider (IdP) | Responsabile di autenticare l’utente e rilasciare token di sicurezza |
| Resource Server | Server che ospita risorse o API protette, accessibili solo tramite token validi |
| OpenID Provider (OP) | Authorization Server che implementa lo standard OpenID Connect |
Nel nostro setup utilizziamo il flusso Authorization Code per garantire un’autenticazione robusta e sicura in contesti web e mobile.
Ecco come funziona, passo per passo:
Passo 1 – Redirect iniziale
Il client reindirizza l’utente verso l’endpoint /authorize dell’IdP, passando:
client_idredirect_uriscope=openid- altri parametri di configurazione (es.
response_type=code)
Passo 2 – Autenticazione e verifica MFA
L’utente inserisce le proprie credenziali. Se previsto, l’IdP richiede anche una verifica a più fattori (MFA), aumentando la sicurezza.
Dopo che l’utente ha eseguito l’autenticazione e dato il consenso, l’IDP restituisce una risposta all’app nell’URI di reindirizzamento indicato usando il metodo specificato nel parametro response_mode.
La risposta con esito positivo quando si usa response_mode=form_post è simile alla seguente:
| Parametro | Descrizione |
|---|---|
id_token | Token ID richiesto dall’app. È possibile usare il parametro id_token per verificare l’identità dell’utente e avviare una sessione con l’utente. |
state | Se nella richiesta è incluso un parametro state(non obbligatorio), lo stesso valore deve essere visualizzato nella risposta. L’app deve verificare che i valori state nella richiesta e nella risposta siano identici. |
Le risposte di errore possono essere inviate anche all’URI di reindirizzamento in modo che l’app possa gestirle, ad esempio:
| Parametro | Descrizione |
|---|---|
error | Stringa di codice di errore che può essere usata per classificare i tipi di errori che si verificano e correggerli. |
error_description | Messaggio di errore specifico che consente di identificare la causa principale di un errore di autenticazione. |
Passo 3 – Rilascio dell’Authorization Code
Dopo l’autenticazione, l’IdP reindirizza il browser del client verso il redirect_uri, allegando un authorization code temporaneo, che rappresenta il permesso di scambiare l’identità autenticata.
Passo 4 – Scambio del codice per token
Il client invia una richiesta POST all’endpoint /token dell’IdP, includendo:
- L’authorization code ricevuto
client_ide, se previsto,client_secret
Se la richiesta è valida, l’IdP restituisce:
- ID Token (JWT firmato), che contiene i dati di identità dell’utente
- Access Token
- È un JWT destinato a essere letto dal client OAuth, che è il destinatario del token.
Può contenere anche informazioni sull’utente, come il nome o l’indirizzo e-mail.
Le applicazioni client possono utilizzarlo per costruire un profilo utente e personalizzare l’esperienza dell’utente
- È un JWT destinato a essere letto dal client OAuth, che è il destinatario del token.
- Refresh Token (opzionale), per rinnovare i token senza nuovo login
Passo 5 – Accesso e verifica token
Il client:
- Decodifica e verifica la firma dell’ID Token usando la chiave pubblica dell’IdP
- Utilizza l’Access Token per autorizzare le richieste alle risorse protette
- Gestisce la sessione utente senza necessità di ulteriori login finché i token sono validi
Passo 6 – Recupero delle informazioni utente tramite Access Token
Dopo aver ricevuto i token dall’Authorization Server, il client utilizza l’Access Token per richiedere informazioni aggiuntive sull’utente direttamente dall’endpoint /userinfo dell’OpenID Provider.
- Il client invia una chiamata API al
/userinfo, includendo l’Access Token nell’headerAuthorization: Bearer <access_token>.
- Il server risponde con un payload JSON contenente claims aggiuntivi sull’utente, come nome, email, ruolo, ecc.
- Questo consente al client di ottenere dati dinamici e aggiornati senza doverli includere tutti nell’ID Token, mantenendo così i token più leggeri e sicuri.
Qui sotto trovi un grafico esplicativo tratto da Authorization Code Flow che illustra passo dopo passo il flusso di Authorization Code Flow con OpenID Connect, mostrando come avviene l’interazione tra utente, client e Identity Provider per un login sicuro e senza interruzioni.
Se vuoi approfondire o implementare la soluzione, ecco alcune risorse aggiuntive:
- 🔗 An Illustrated Guide to OAuth and OpenID Connect
- 🔗 Creating an OpenID connect system
- 🔗 OpenID Connect Official Site
- 🔗 Auth0: Authorization Code Flow Explained
- 🔗 Microsoft Identity Platform Documentation
- 🔗RFC 6749: The OAuth 2.0 Authorization Framework
Glossario del developer
- OpenID Connect (OIDC) è un moderno protocollo di autenticazione progettato per identificare in modo sicuro gli utenti e consentire alle applicazioni di fidarsi di tale identità senza dover gestire direttamente le password. Si basa su protocolli standard, facilitando flussi di autenticazione sicuri e flessibili, particolarmente adatti ad ambienti cloud e orientati alle API. OIDC rilascia token, come gli ID Token, che contengono informazioni sull’identità dell’utente, migliorando sicurezza ed esperienza d’uso all’interno delle applicazioni integrate.
↩︎ - HIPAA, acronimo di Health Insurance Portability and Accountability Act, è una legge statunitense creata per proteggere le informazioni sanitarie sensibili dei pazienti, impedendone la divulgazione senza il consenso o la conoscenza dell’interessato. Stabilisce standard per la privacy e la sicurezza dei dati sanitari, garantendo che fornitori di servizi sanitari, assicurazioni e loro partner commerciali mantengano la riservatezza e l’integrità delle informazioni dei pazienti. La conformità a HIPAA è fondamentale per le organizzazioni che gestiscono dati sanitari, al fine di evitare sanzioni legali e preservare la fiducia dei pazienti.
↩︎ - MFA, ovvero autenticazione a più fattori (Multi-Factor Authentication), è un meccanismo di sicurezza che richiede agli utenti di fornire due o più fattori di verifica per accedere a un’applicazione o a un sistema. Questo processo aumenta la protezione combinando qualcosa che l’utente conosce (come una password) con qualcosa che l’utente possiede (ad esempio un’app sullo smartphone per generare codici) o qualcosa che l’utente è (verifica biometrica). L’MFA riduce in modo significativo il rischio di accessi non autorizzati, rendendola un elemento fondamentale dei protocolli di sicurezza moderni.
↩︎ - Identity Provider (IdP) è un sistema centrale responsabile della gestione e della verifica degli accessi degli utenti. Autentica gli utenti durante i tentativi di login, gestisce in modo sicuro le credenziali (spesso con supporto per l’autenticazione a più fattori) e rilascia token digitali che consentono di accedere alle applicazioni senza dover inserire ripetutamente nome utente e password. Le applicazioni si fidano dei token emessi dall’IdP, garantendo un’esperienza utente fluida e sicura su vari servizi.
↩︎ - SAML (Security Assertion Markup Language) è uno standard aperto per lo scambio di dati di autenticazione e autorizzazione tra diverse parti, in particolare tra un provider di identità e un provider di servizi. Consente il Single Sign-On (SSO), permettendo agli utenti di autenticarsi una sola volta e accedere a più applicazioni senza dover effettuare nuovamente il login per ciascuna di esse. SAML utilizza asserzioni basate su XML per trasmettere in modo sicuro l’identità e gli attributi dell’utente.
↩︎
