7 passaggi per il Single Sign-On per applicazioni personalizzate per ingegneri e PM

7 passaggi per il Single Sign-On per applicazioni personalizzate per ingegneri e PM

Per le nuove applicazioni web o mobili personalizzate, utilizzate OpenID Connect con il flusso del codice di autorizzazione più PKCE; riservate SAML ai casi in cui sia necessario interoperare con provider di identità aziendali legacy. Prima di scrivere codice, assicuratevi di avere pronti: un URI di reindirizzamento registrato, un ID client, un URL dell’emittente o dei metadati e l’accesso all’endpoint JWKS del provider. Verificate che PKCE utilizzi il metodo S256, che i token siano limitati a un’unica audience e che i parametri nonce e state vengano convalidati nel callback.

In breve:

• Utilizzate OpenID Connect con il codice di autorizzazione e PKCE per le nuove applicazioni cloud-native, riservando SAML esclusivamente alle integrazioni aziendali legacy.
• Verificate la convalida completa di PKCE e la limitazione dell’audience dei token, quindi convalidate i parametri nonce e state a ogni callback per garantire la sicurezza.
• Supportate entrambi i protocolli quando necessario, ma utilizzate OIDC come impostazione predefinita per le applicazioni moderne, soprattutto con architetture API e mobili, mantenendo il supporto a SAML per i partner aziendali.
• Registrate correttamente le applicazioni, convalidate l’emittente e JWKS e testate la validità dei token e la sincronizzazione dell’orologio prima della distribuzione in produzione; mantenete ambienti di staging e produzione separati.
• Implementate una convalida accurata del logout, monitorate gli errori comuni come le discrepanze negli URI di reindirizzamento e preparatevi alla rotazione dei certificati con runbook operativi dettagliati.

Indice

• Scegliere tra OIDC e SAML per le applicazioni personalizzate
• Implementazione passo passo di OpenID Connect per applicazioni personalizzate
• Integrazione di SAML 2.0 per i provider di identità aziendali
• Implementare correttamente il codice di autorizzazione più PKCE
• Dove devono risiedere i token: pattern BFF, SPA e mobile
• Gestire correttamente il logout e la terminazione della sessione
• Checklist di test ed errori comuni nella distribuzione del Single Sign-On
• Standard di sicurezza da citare in ogni revisione della progettazione del Single Sign-On
• Una checklist operativa basata sul lavoro di delivery
• Ottenete assistenza per implementare il Single Sign-On nella vostra applicazione personalizzata
• Fonti
• Domande frequenti

Scegliere tra OIDC e SAML per le applicazioni personalizzate

La scelta del protocollo dipende solitamente dal tipo di applicazione che state sviluppando e dagli interlocutori con cui dovete comunicare. OpenID Connect è consigliato per le nuove applicazioni cloud-native, poiché si basa su OAuth 2.0 ed è progettato per integrarsi naturalmente nelle architetture web e API. SAML 2.0 rimane comune nelle integrazioni B2B aziendali, in particolare quando il provider di identità ha decenni di vita e il team responsabile dell’integrazione non ha in programma di modernizzarlo.

I compromessi sono pratici, non filosofici. SAML si basa sullo scambio di metadati XML e sulla fiducia basata sui certificati, il che significa che la rotazione dei certificati e la mappatura degli attributi diventano attività di manutenzione ricorrenti. OIDC si basa sui JSON Web Token e su un documento di discovery, che la maggior parte delle librerie attuali gestisce con una quantità molto inferiore di codice personalizzato.

Prima di adottare un protocollo per l’intera applicazione, valutate alcuni aspetti:

• Architettura dell’applicazione: Le applicazioni a pagina singola, le applicazioni mobili e i backend API-first si adattano più naturalmente al modello dei token di OIDC rispetto alle ipotesi di reindirizzamento del browser proprie di SAML.
• Panorama degli IdP dei partner: Se i vostri clienti aziendali espongono esclusivamente endpoint SAML, dovrete supportarlo indipendentemente dalle vostre preferenze.
• Complessità multi-tenant: Se supportate più IdP dei clienti, pianificate fin dall’inizio la ricerca dell’emittente, la verifica del dominio e l’home realm discovery, poiché introdurre il routing dei tenant dopo il lancio è problematico.

La maggior parte dei team finisce per supportare entrambi, con OIDC come impostazione predefinita e SAML come soluzione per specifici account aziendali.

Implementazione passo passo di OpenID Connect per app personalizzate

Una volta scelto OIDC, la sequenza di implementazione è abbastanza uniforme tra i vari provider, che si utilizzi Okta, Azure AD o un'altra piattaforma di identità.

1. Registra l'applicazione presso il tuo provider di identità, specificando il tipo di client (pubblico o riservato), gli URI di reindirizzamento esatti e le origini consentite per CORS.
2. Recupera il documento di discovery dall' /.well-known/openid-configuration endpoint del provider e memorizza nella cache gli URL dell'issuer e di JWKS.
3. Convalida l'issuer in ogni token ricevuto, confrontandolo esattamente con il valore indicato nel documento di discovery.
4. Richiedi lo openid scope come minimo, aggiungendo profile o email solo se la tua app ha effettivamente bisogno di questi claim.
5. Avvia il flusso Authorization Code con PKCE, generando un code verifier e una code challenge con hash S256 prima di reindirizzare l'utente.
6. Convalida il id_tokenrestituito, verificando iss, aud, exp, e il nonce generato all'inizio del flusso, come raccomandato dalle linee guida OAuth2 di OWASP.
7. Gestisci correttamente i segreti: i client riservati memorizzano il client secret esclusivamente lato server; i client pubblici si affidano interamente a PKCE.

Alcuni dettagli di distribuzione mettono in difficoltà i team che saltano gli ambienti di staging: nella maggior parte dei provider, gli elenchi di URI di reindirizzamento consentiti richiedono una corrispondenza esatta, quindi una differenza dovuta a una barra finale farà fallire silenziosamente la procedura o genererà un errore poco chiaro. Una differenza di orario tra il server e l'IdP può far rifiutare token validi perché considerati scaduti. Esegui i test con un tenant IdP di staging e una propria registrazione del client prima di utilizzare le credenziali di produzione.

Consiglio pratico: Mantieni registrazioni del client separate per staging e produzione, anche se questo significa raddoppiare il lavoro di configurazione: condividere un elenco di URI di reindirizzamento consentiti tra gli ambienti è una causa comune di sorprese del tipo «in staging funzionava».

Integrazione di SAML 2.0 per i provider di identità aziendali

Le integrazioni SAML seguono una dinamica diversa, basata sullo scambio di metadati anziché sugli endpoint di discovery. La configurazione del SSO SAML richiede la registrazione degli URL di reindirizzamento e ACS, lo scambio di metadati o certificati e l'allineamento dei valori dell'issuer tra service provider e identity provider; le discrepanze in questo ambito sono la causa più frequente degli accessi non riusciti.

Passaggi pratici per un'integrazione pulita:

• Scambia tempestivamente i metadati di SP e IdP includendo l'URL dell'Assertion Consumer Service (ACS) e il tuo Entity ID, così entrambe le parti concordano sulla destinazione a cui inviare le asserzioni.
• Gestisci i certificati in modo mirato: quando disponibile, recuperali dall'endpoint dei metadati dell'IdP anziché codificare direttamente un certificato che prima o poi scadrà.
• Mappa gli attributi SAML nel modello di autorizzazione della tua app usando un elenco di elementi consentiti esplicito e verifica la mappatura con un utente di test dedicato per ogni tenant prima di estenderla agli account reali.

Gli errori specifici di SAML tendono a concentrarsi su alcune cause ricorrenti: asserzioni non firmate o firmate in modo errato, differenze di orario tra l'IdP e il server e discrepanze nelle restrizioni del pubblico, quando il destinatario previsto dell'asserzione non corrisponde al tuo Entity ID.

Consiglio pratico: Durante i test di integrazione, registra la risposta SAML non elaborata (escludendo i valori degli attributi sensibili). I problemi relativi agli spazi dei nomi XML sono molto più facili da individuare in un payload non elaborato che in una traccia dello stack distante tre livelli dall’asserzione effettiva.

Implementare correttamente il codice di autorizzazione con PKCE

PKCE esiste per colmare una lacuna specifica: senza di esso, il codice di autorizzazione intercettato può essere riscattato da chiunque lo abbia catturato. PKCE associa la richiesta di autorizzazione iniziale allo scambio del token mediante un verificatore, così anche un codice sottratto è inutilizzabile senza il verificatore corrispondente. Il flusso del codice di autorizzazione con PKCE è ormai la pratica di sicurezza di riferimento per i client pubblici, con S256 come metodo consigliato per la code challenge rispetto al metodo plain, più debole.

I meccanismi sono semplici dopo averli implementati una volta: genera un verificatore del codice casuale, sottoponilo a hashing con SHA-256 per produrre la code challenge, invia la challenge nella richiesta di autorizzazione e presenta il verificatore originale quando scambi il codice con i token. Gli aspetti su cui i team commettono errori sono:

• Saltare la convalida del nonce, annullando così una delle principali protezioni contro gli attacchi di replay nel livello OIDC.
• Consentire il riutilizzo del codice, quando il codice dovrebbe essere monouso e invalidato immediatamente dopo il primo tentativo di scambio.
• Archiviare il verificatore in modo non sicuro, ad esempio in una posizione accessibile a qualsiasi script in esecuzione sulla pagina di un’app basata su browser.

I client riservati, ovvero le app lato server che possono custodire in sicurezza un segreto, combinano comunque PKCE con un segreto client in molte implementazioni. I client pubblici, come le SPA e le app mobili native, si affidano esclusivamente a PKCE, poiché non possono mantenere riservato un segreto.

Dove archiviare i token: pattern BFF, SPA e mobile

La posizione dei token determina gran parte dell’esposizione dell’app al furto dei token. Il pattern backend-for-frontend mantiene i token lato server e fornisce invece al browser un cookie HttpOnly di breve durata: una configurazione diventata la raccomandazione standard per le app a pagina singola che chiamano API private.

La RFC 9700 descrive i token vincolati al mittente e associati crittograficamente come una direzione emergente per ridurre il rischio di replay, indicando che le decisioni odierne sulla progettazione della gestione dei token dovrebbero tenere conto di potenziali requisiti di associazione più rigorosi.

Regole pratiche per la topologia dei token:

• Client riservati custodiscono i segreti lato server; client pubblici si affidano a PKCE e a token di accesso di breve durata invece che a un segreto.
• Limita i token di accesso a un singolo pubblico per ogni API e non accettare mai un token ID come se fosse un token di accesso all’API.
• Ruota i token di aggiornamento a ogni utilizzo e rileva il riutilizzo di un token ritirato come segnale di un possibile furto.

Le app mobili seguono generalmente il modello dei client pubblici e archiviano i token nell’archiviazione sicura fornita dalla piattaforma (Keychain su iOS, Keystore su Android), anziché in file normali.

Gestire correttamente il logout e la terminazione della sessione

Il logout singolo sembra semplice finché non si considera chi lo ha avviato e quanto lontano debba propagarsi. Nel logout avviato dal service provider (SP), l’app comunica all’IdP che l’utente ha terminato la sessione; nel logout avviato dall’IdP, è l’IdP a comunicare a ogni app connessa di terminare la sessione. Entrambe le direzioni richiedono la convalida del messaggio in ingresso.

Il Single Logout SAML richiede un’attenta convalida delle richieste di logout, poiché le implementazioni ingenue espongono a rischi di denial-of-service o di logout forzato, in cui un utente malintenzionato invia un messaggio di logout non autenticato per espellere un utente legittimo.

Implementa il logout con queste misure di sicurezza:

• Convalida ogni richiesta di logout per verificarne la firma e id_token_hint prima di procedere.
• Considera il logout globale come un’operazione best effort: termina immediatamente la sessione locale, quindi prova a inviare le notifiche ai sistemi a valle invece di bloccare l’operazione in attesa del loro completamento.
• Nello specifico per SAML, richiedi richieste di logout firmate e configura esplicitamente l’endpoint SLO, invece di presupporre un valore predefinito.

Checklist di test ed errori comuni nella distribuzione del SSO

Prima del rilascio, esegui una breve checklist preliminare invece di scoprire i problemi in produzione.

1. Verifica che gli URI di reindirizzamento corrispondano esattamente, incluse le barre finali e il protocollo.
2. Verifica l’allineamento dell’emittente e dei metadati tra la configurazione della tua app e ciò che l’IdP pubblica effettivamente.
3. Verifica la disponibilità di JWKS e conferma che la tua app possa recuperare e memorizzare nella cache le chiavi di firma.
4. Sincronizza gli orologi dei server, poiché anche uno scarto di pochi minuti causa errori nella convalida dei token.
5. Esegui i test con un tenant IdP di staging utilizzando account dedicati prima di intervenire sulle credenziali di produzione.

Gli errori più comuni corrispondono a correzioni specifiche: invalid_redirect_uri quasi sempre indica una mancata corrispondenza esatta nella allowlist, mentre un’incongruenza dell’emittente di solito significa che la tua app ha memorizzato nella cache un documento di discovery obsoleto. Registra gli eventi di autenticazione, inclusi i tentativi non riusciti e i tentativi di riutilizzo, senza memorizzare mai i token non elaborati nei log.

Standard di sicurezza a cui ogni revisione della progettazione SSO dovrebbe fare riferimento

Alcuni documenti dovrebbero costituire il riferimento di qualsiasi progettazione SSO o revisione della sicurezza. RFC 9700 definisce l’attuale baseline di sicurezza di OAuth 2.0, mentre RFC 7636 definisce il meccanismo PKCE da cui tale baseline dipende. Le linee guida OWASP ASVS per OAuth e OIDC considerano il livello OAuth e OIDC come un perimetro di sicurezza che merita un audit separato.

Controlli da applicare in ogni revisione:

• Limita ogni token all’audience prevista e rifiuta, sul lato del resource server, i token che non sono stati emessi per esso.
• Prediligi un’autenticazione del client più robusta come private_key_jwt o TLS reciproco rispetto ai segreti condivisi, quando il tuo provider li supporta.
• Ruota i certificati e i token di aggiornamento secondo una pianificazione prestabilita e implementa la revoca e il rilevamento dei replay, invece di affidarti esclusivamente alla scadenza dei token.

Consiglio: Imposta un promemoria sul calendario 30 giorni prima della scadenza di qualsiasi certificato SAML. La scadenza di un certificato è un’interruzione del servizio prevenibile, non una sorpresa.

Una checklist operativa basata sul lavoro di delivery

Far funzionare SSO in una demo è la parte facile. Farlo resistere a un lancio in produzione, alla rotazione di un certificato e a un’interruzione dell’IdP sei mesi dopo richiede un po’ più di disciplina.

• Separa completamente staging e produzione con registrazioni client, account utente di test ed endpoint dei metadati distinti.
• Prepara una procedura operativa per la rotazione dei certificati con finestre di sovrapposizione e avvisi 30 giorni prima della scadenza, automatizzando l’acquisizione dagli endpoint dei metadati quando il provider lo supporta.
• Consegna una documentazione completa, inclusi una procedura operativa per la revoca dei token, dashboard di monitoraggio per gli errori di autenticazione e script di test di accettazione che il team del cliente possa rieseguire dopo qualsiasi modifica.

I team che saltano la documentazione di consegna tendono a reimparare queste lezioni durante un incidente, invece che in un tranquillo pomeriggio qualunque.

Richiedi assistenza per implementare SSO nella tua applicazione personalizzata

Se il tuo team ha già definito la progettazione ma ha bisogno di supporto per realizzarla, Ridiculous Engineering gestisce l’intero percorso: revisione dell’architettura, implementazione di OIDC o SAML, test con tenant IdP di staging e configurazione della procedura operativa e del monitoraggio necessari per mantenerla operativa dopo il lancio. Lavoriamo tramite incarichi di sviluppo software personalizzato dimensionati in base al problema, non secondo un modello fisso, e preferiamo spiegare onestamente un compromesso piuttosto che vendere troppo una scorciatoia. Se stai valutando se sviluppare questa soluzione internamente o affidarti a un team che ha già affrontato i problemi legati alla rotazione dei certificati e alle discrepanze degli URL di callback, contattaci tramite la nostra pagina dei contatti e parleremo di ciò di cui la tua app ha effettivamente bisogno.

Fonti

• RFC 9700: OAuth 2.0 Security Best Current Practice
• Single sign-on (SSO) di Microsoft Entra
• OAuth2 - OWASP Cheat Sheet Series

FAQ

Come creo il mio SSO?

L’SSO si implementa integrando la propria app con un provider di identità tramite OpenID Connect o SAML, anziché sviluppare l’autenticazione da zero. Per le nuove app, OpenID Connect con il flusso Authorization Code e PKCE è il punto di partenza standard, gestito tramite SDK del provider come quelli di Okta o Azure AD.

L’SSO è rischioso?

L’SSO non è intrinsecamente più rischioso degli accessi specifici per app e in genere riduce il rischio centralizzando l’autenticazione presso un provider con controlli di sicurezza più solidi di quelli che la maggior parte delle singole app potrebbe realizzare autonomamente. Il rischio reale risiede negli errori di implementazione, come saltare PKCE, non convalidare l’audience del token o gestire in modo errato il logout; tutti aspetti trattati direttamente dalle linee guida OWASP su OAuth2.

È possibile usare l’SSO in un’app mobile?

Sì, le app mobile implementano comunemente l’SSO come client pubblici OAuth 2.0 utilizzando il flusso Authorization Code con PKCE, poiché non possono conservare in modo sicuro un client secret. I token vengono in genere archiviati nell’archiviazione sicura nativa della piattaforma, anziché in file dell’app in chiaro.

Quali sono i principali provider SSO?

Tra i provider di identità comunemente utilizzati per le integrazioni SSO figurano Okta e Azure AD di Microsoft (ora parte di Microsoft Entra), oltre ad altri. La scelta giusta dipende dai protocolli che l’app deve supportare e dai provider che i clienti aziendali utilizzano già.

Come funziona il logout singolo tra le app?

Il logout singolo può essere avviato dalla propria app (avviato dall’SP) o dal provider di identità (avviato dall’IdP); in entrambi i casi è necessario convalidare il messaggio di logout prima di agire. Implementazioni SAML del logout non sufficientemente rigorose possono esporre a rischi di denial-of-service o di logout forzato, quindi la maggior parte dei team considera il logout globale un’operazione soggetta al buon esito, anziché un kill switch istantaneo garantito per ogni app connessa.

Consigliato

• Framework di ingegneria AI-Speed
• Cosa rende un’app davvero coinvolgente? Ecco la nostra ricetta segreta!
• Project Manager, Product Owner e Business Analyst nell’e-commerce e nello sviluppo di applicazioni: quale figura ti serve?