Come scegliere un provider di identità: Il framework di valutazione del team di ingegneria

La maggior parte degli articoli di confronto tra provider di identità sono scritti dai provider di identità stessi. Scioccante, vero? Elencano le funzionalità che il loro prodotto offre, saltano quelle che non ha e lo chiamano una "guida obiettiva".

Questo non è quel tipo di guida.

Abbiamo analizzato dozzine di richieste reali di valutazione aziendale — le effettive spreadsheet e i documenti RFP che i team di procurement inviano ai fornitori. I pattern sono chiari: i team di ingegneria danno costantemente poco peso ai criteri più importanti e troppo a quelli meno rilevanti.

Il risultato? I team scelgono un IdP dopo una demo, scoprono che la storia della migrazione è un incubo dopo sei mesi, e ricominciano a valutare da capo.

Ecco il framework di valutazione che avremmo voluto qualcuno ci avesse dato prima di iniziare. È costruito per i team di ingegneria di aziende SaaS B2B — quelli che costruiscono prodotti, non quelli che acquistano SSO workforce per i loro dipendenti.

Risposta rapida: Cosa determina la scelta di un IdP#

Se stai leggendo velocemente, ecco la versione breve:

1. La profondità del protocollo conta più del numero di funzionalità. Dire di supportare "OAuth2" non significa niente. Quali grant type? Puoi personalizzare le dichiarazioni (claims) dei token? Puoi diventare tu stesso un provider OIDC?
2. La capacità di migrazione è il criterio N.1 sottovalutato. Se non puoi migrare i tuoi utenti esistenti senza forzare il reset delle password, l'IdP è inutilizzabile — indipendentemente da quanto sembri buono tutto il resto.
3. La multi-tenancy deve essere nativa, non aggiunta a posteriori. Se i modelli di organizzazione e le configurazioni per tenant richiedono workaround, starai combattendo contro il sistema per sempre.
4. L'idoneità all'IA non è pianificazione futura: è una necessità nei prossimi 12 mesi. Token exchange, identità dell'agente, scope delegati. Se l'IdP non li supporta, tornerai a valutare già l'anno prossimo.

Il resto di questa guida analizza ogni dimensione di valutazione nel dettaglio, con domande specifiche da fare e bandiere rosse da monitorare.

Per chi è questa guida (e per chi non lo è)#

Questa guida è per te se:

• Sei un CTO, VP of Engineering, o platform architect in un'azienda SaaS B2B da 50-300 persone
• Hai oltre 100.000 utenti esistenti e non puoi permetterti una migrazione dirompente
• Ti stai espandendo verso clienti enterprise che richiedono SSO, modelli organizzativi e audit log
• Devi scrivere un report tecnico di valutazione e vuoi un framework che non provenga da un fornitore

NON è per te se:

• Cerchi un IAM workforce (SSO per dipendenti verso tool interni) — è una decisione di acquisto differente
• Sei una startup con 500 utenti e senza clienti enterprise — scegli ciò che ha il miglior SDK e vai avanti
• Ti serve una verifica d'identità (KYC/KYB) — è tutta un'altra categoria

Dimensione 1: Capacità dei protocolli — Non solo "supporta OAuth2"#

Ogni IdP sul mercato ti dirà che supporta OAuth2 e OIDC. Quella è la base minima. Le vere domande riguardano la profondità.

Grant Type: Quali supportano e perché importa#

Must-have:

• Authorization Code + PKCE — È l'unico flow che dovresti usare per web e mobile app. Se un fornitore raccomanda ancora il flusso Implicit, lascia perdere. PKCE non è opzionale — è un requisito di sicurezza.
• Client Credentials — Per la comunicazione service-to-service. I tuoi backend devono autenticarsi tra loro senza presenza utente.
• Refresh Token — Sembra banale, ma le implementazioni cambiano molto. Puoi configurare rotazione? Scadenza? Puoi revocare un singolo refresh token senza annullare tutta la sessione?

Sempre più critico:

• Token Exchange (RFC 8693) — È il grant che abilita autenticazione di agenti AI, flussi di impersonificazione e delega. Se manca, chiedi della roadmap. Se non c'è roadmap, è una bandiera rossa.

Capacità di essere Provider OIDC#

Ecco una domanda che pochi si pongono: Puoi usare questo IdP come OIDC Provider — non solo come consumer?

Perché importa: Quando il tuo SaaS cresce, partner e clienti vorranno usare il tuo sistema di identità per accedere ai loro strumenti. Devi poter emettere token, gestire il consenso e registrare app di terze parti. Se il tuo IdP ti permette solo di consumare provider esterni ma non di agire come provider, avrai problemi al momento della federazione verso l'esterno.

Chiedi:

• L'IdP espone un endpoint OpenID Discovery personalizzabile?
• Puoi registrare app first-party e third-party con livelli di fiducia diversi?
• Le app first-party possono saltare la schermata di consenso mentre quelle third-party la richiedono?

Personalizzazione dei JWT#

Il token è il contratto tra il tuo IdP e i tuoi servizi. Se non puoi personalizzarlo, ogni servizio dovrà fare chiamate API aggiuntive per capire cosa l'utente può fare.

Chiedi:

• Puoi aggiungere claim personalizzati ai token di accesso e ID?
• Puoi inserire il contesto organizzativo (su quale tenant sta operando l'utente) direttamente nel token?
• Puoi definire scope personalizzati che mappino il modello di permesso della tua applicazione?
• Le claim sono calcolate al momento dell'emissione del token, o possono essere popolate dinamicamente tramite webhook o script?

Un token che contiene { "org_id": "org_123", "role": "admin", "auth_level": 2 } permette al tuo middleware API di prendere decisioni di autorizzazione in una linea di codice. Un token che ha solo { "sub": "user_456" } obbliga ogni servizio a richiamare l’IdP o un database per saperne di più. Su larga scala, quella differenza significa 2 ms contro 200 ms per richiesta.

Dimensione 2: Flussi di autenticazione — I dettagli che ti fregano#

Ogni IdP supporta email/password e login social. Complimenti, hai ristretto il campo a... tutti.

La vera differenziazione sta nei dettagli che i demo non coprono quasi mai.

Il flusso di registrazione#

• Auto-login post registrazione: Dopo che un utente si registra, viene loggato automaticamente? O rivede la pagina di login? Costringere l’utente a rieffettuare il login uccide la conversione. Sorprendente quanti IdP sbaglino questa cosa.
• Campi personalizzati in registrazione: Puoi raccogliere ruolo, nome azienda, o use case durante la registrazione? O devi fare onboarding separato successivamente?
• Progressive profiling: Puoi raccogliere informazioni aggiuntive su più sessioni invece che esigere tutto subito?

Il flusso di login#

• Supporto login_hint: Quando un utente clicca un link da un’email marketing, puoi pre-compilare il suo indirizzo email? Sembra marginale, ma non lo è. Fa la differenza tra un 40% e un 60% di conversione per quelle campagne.
• Policy di autenticazione specifiche per organizzazione: Org A può richiedere SAML SSO mentre Org B email/password. Puoi imporre MFA solo per enterprise tenant? Se ogni policy tenant richiede cambi di codice invece che solo di configurazione, sprecherai settimane di lavoro per ogni nuovo cliente enterprise.
• Personalizzazione branding: Puoi personalizzare l’esperienza di login per tenant? Non solo logo e colori — proprio CSS, domini personalizzati ed email white-label. Scegli tra Hosted UI o la tua UI: non deve essere una limitazione imposta dal provider.

Cosa manca nelle checklist#

• Autenticazione silenziosa: Alla scadenza di un token, puoi fare refresh in background senza redirect per l’utente? Se anche il refresh token è scaduto, esiste un fallback (come sessione dinamica via iframe)?
• Collegamento account: Un utente si registra con Google e poi tenta login tramite email. Sono due account diversi o uno solo? Come gestisce l’IdP la fusione di identità? Sbagliare qui = account duplicati fantasma per sempre.
• Opzioni passwordless: Magic link, passkey, WebAuthn. Non perché servano a tutti oggi, ma i tuoi clienti enterprise li chiederanno in 6 mesi.

Dimensione 3: Gestione di sessioni e token — Qui si decide tutto#

Qui si divide chi valuta davvero da chi si ferma alla demo. La gestione di sessioni e token è noiosa... finché non si rompe. E quando succede, tutti gli utenti vengono deautenticati in blocco.

Sicurezza dei cookie#

Non è sexy. Ma è vitale.

• Attributi HttpOnly, Secure, SameSite: Devono essere settati correttamente tutti e tre. Un IdP che non imposta HttpOnly sui session cookie non è pronto per la produzione.
• Supporto cross-subdomain: Se la tua app gira su app.prodottotuo.com e la tua API su api.prodottotuo.com, le sessioni coprono entrambi i subdomini? Come?
• Deprecazione dei third-party cookie: Chrome li sta deprecando. Come gestisce l'IdP i flow cross-origin senza di loro? Se la risposta è “ci stiamo lavorando”, non basta.

Remember me e sessioni persistenti#

Gli utenti vogliono rimanere loggati per settimane, non minuti. Ma una sessione da 180 giorni ha implicazioni molto diverse da una da 30 minuti.

Chiedi:

• Puoi configurare la durata della sessione indipendentemente dalla durata del token?
• Sì/no per un'opzione "remember me" che estenda la sessione senza allungare la vita dei token?
• Puoi forzare la ri-autenticazione per operazioni sensibili senza terminare la sessione?

Sicurezza dei refresh token#

• Rotazione del token: L’IdP ruota i refresh token ad ogni uso? (Dovrebbe!)
• Archiviazione criptata: I refresh token sono criptati a riposo?
• Revoca granulare: Puoi revocare la sessione di un singolo device senza recidere tutte le sessioni?
• Scadenza configurabile: Ogni app può avere la sua durata di refresh token, o è globale?

Dimensione 4: Modello di autorizzazione — Oltre il RBAC base#

Il Role-Based Access Control è la base. Se l’IdP non supporta RBAC, non vale nemmeno la valutazione. Ma per SaaS B2B, il solo RBAC non basta.

Permessi con scope organizzativo#

I tuoi utenti appartengono ad organizzazioni. I permessi all’interno di un’organizzazione sono diversi da quelli a livello di piattaforma.

Un utente può essere admin in Org A e viewer in Org B. Stesso utente, due ruoli diversi. Se l’IdP non sa modellarlo nativamente, dovrai costruirti un sistema parallelo di permessi = doppio source of truth.

Domande:

• Puoi definire ruoli a livello di organizzazione, non solo utente?
• Un utente può avere ruoli diversi tra più organizzazioni?
• Il contesto dell’organizzazione attuale è inserito nel token, così che l’API sappia per quale org sta agendo l’utente?

Autorizzazione multilivello (auth_level)#

Per applicazioni finanziarie, healthcare o con funzioni ad alto rischio: non tutte le sessioni sono uguali.

Vedere una dashboard? Basta il cookie di sessione. Inviare un bonifico? Serve una verifica MFA aggiuntiva anche se l’utente è già autenticato.

Questo è step-up authentication: serve che il concetto di authentication level (auth_level) sia nel token come cittadino di prima classe.

Chiedi:

• Il token può portare la claim auth_level per controlli in backend?
• Puoi attivare lo step-up authentication dall’app senza forzare un nuovo login completo?
• auth_level ha una sua scadenza indipendente dalla sessione?

Se l’IdP non lo supporta nativamente, dovrai fartelo da te — proprio quel tipo di logica identitaria che stai pagando l’IdP per evitare.

Autorizzazione basata su token#

L’ideale: il tuo middleware API legge il token, vede org, ruolo, auth_level, decide subito senza chiamare servizi esterni.

La realtà di molti IdP: il token ti dice solo chi è l’utente, non cosa può fare — serve una API extra per saperlo.

Quella chiamata aggiunge latenza, dipendenza e possibilità di fallimento. A 1.000 richieste/sec, non vuoi che ogni autorizzazione passi da una chiamata di rete.

Dimensione 5: Migrazione — Il criterio che decide davvero tutto#

Ecco una statistica scomoda: la maggior parte delle valutazioni IdP saltano non perché il nuovo IdP sia inadeguato, ma perché il team non sa come migrare gli utenti esistenti.

Se hai 100.000+ utenti, la migrazione non è un “nice to have” — è tutto il progetto.

Tre strategie di migrazione (e cosa l’IdP deve supportare)#

1. Bulk import di password hash esistenti

I tuoi utenti hanno password storate con bcrypt, argon2 ecc. L’IdP può importarne direttamente gli hash e verificarli?

Se sì: l’utente logga con la sua password, per lui non cambia niente. Scenario ideale.

Se no: tutti ricevono l’email “ripristina password”. Perderai il 30-50% degli utenti nella migrazione. Non è un’ipotesi: l’abbiamo visto succedere.

2. Migrazione progressiva (lazy migration)

Invece di migrare tutti in un colpo, lo fai uno a uno al primo login. Il primo accesso verifica la password nel vecchio sistema e crea l’utente nel nuovo IdP. Da lì in poi il login si fa solo sul nuovo sistema.

Soluzione più sicura per grandi base utenti, ma richiede che l’IdP supporti:

• Un hook di autenticazione personalizzato che chiama il vecchio sistema
• Creazione utente al volo durante il login
• Tracciamento degli utenti migrati vs. non migrati

3. Dual-write (sistemi attivi in parallelo)

Durante la transizione entrambi i sistemi di identità sono attivi. Le scritture vanno a entrambi, le letture si spostano gradualmente. Così c’è rollback, ma aggiunge complessità operativa.

Bandiere rosse sulla migrazione#

• "Supportiamo import CSV" — Vuol dire import di profili, non delle password. Servirà comunque la procedura di reset.
• "Abbiamo una guida di migrazione" — Leggi bene! Se dice “gli utenti devono impostare una nuova password”, sei nel caso di perdita del 30-50%.
• Nessun accenno alla compatibilità degli hash — Se il fornitore non considera la migrazione degli hash password, non ha lavorato con aziende della tua scala.

Domande da porre#

• Quali algoritmi di hash password supportate in import? (bcrypt, argon2, scrypt, PBKDF2, custom?)
• Possiamo fare una migrazione progressiva per utente al primo login?
• Possiamo tracciare l’avanzamento: che percentuale di utenti è migrata?
• Strategia di rollback se la migrazione va male?
• Continuità di sessione: gli utenti restano logged in durante?

Se non sanno rispondere sicuri, non l’hanno mai fatto prima. Vai avanti.

Dimensione 6: Multi-tenancy — Nativo o workaround#

SaaS B2B = multi-tenancy. I tuoi clienti sono organizzazioni, con molti utenti, ruoli, policy di accesso. L’IdP deve capirlo nativamente.

Cosa significa "multi-tenancy nativa"#

• Organizzazione come entità di prima classe: Non un campo custom nel profilo utente, ma modello dati dedicato con proprio ID, config e membri.
• Policy di autenticazione per organizzazione: Org A vuole SAML SSO dalla propria azienda. Org B email/password con MFA obbligatoria. Org C accesso con Google Workspace. Tutto configurabile da UI o API, non con cambi codice.
• Gestione inviti e membership: Gli admin di ogni org invitano utenti, assegnano ruoli, rimuovono membri. L’IdP gestisce flusso inviti, verifica email e assegnazione ruoli.
• Token scoping organizzativo: Quando l’utente agisce su una org, il token include quel contesto. L’API sa subito quali dati restituire.

Il workaround dei "custom metadata"#

Alcuni IdP non hanno il vero modello organizzazione. Propongono di usare metadata custom (user.app_metadata.org_id = "123") come workaround.

Finisce subito male:

• Un utente su più org = array e gestione a mano dei metadata
• Zero flusso nativo per inviti o membership
• Zero policy auth per org
• Niente token scoping — il contesto va dedotto a mano
• Audit log ciechi all’organizzazione

Se dicono “puoi modellare le org via metadata”, è come salvare dati relazionali in una colonna JSON. Funziona... finché non funge più.

Domande da chiedere#

• Il modello organizzazione è nativo o sviluppato sopra i metadata utente?
• Gli utenti possono appartenere a più organizzazioni contemporaneamente?
• Possiamo configurare policy di autenticazione diverse per ogni organizzazione?
• I ruoli e permessi a livello di organizzazione sono nativi?
• Gli admin org possono gestire i membri da una UI self-service?
• Il token include il contesto organizzativo?

Dimensione 7: Idoneità all’IA — Il criterio che quasi nessuno chiede (ancora)#

Dodici mesi fa, “autenticazione agenti AI” non era in nessuna checklist. Oggi, se stai integrando feature AI — copiloti, agenti autonomi, workflow AI-driven — il tuo IdP deve gestire anche una nuova entità: l’agente.

Perché gli agenti rompono il modello tradizionale#

L’autenticazione classica ha due attori: utente e applicazione. OAuth2 è pensato su questo.

Gli agenti AI aggiungono un terzo: entità non umana che agisce per conto di uno specifico utente, con permessi limitati e log di auditing dedicato.

• Un agente non è un utente: non ha password o browser session
• Non è nemmeno un servizio M2M puro — agisce per uno specifico utente
• Serve permessi delimitati, temporanei — non la totalità dei diritti dell’utente

Cosa l’IdP deve supportare#

Token Exchange (RFC 8693): L’agente presenta sia le sue credenziali sia l’autorizzazione dello user, riceve un token con scope. Il token indica: chi (user), cosa (agente), scope (confini), quando (expiry).

Agente come client dedicato: L’agente deve essere modellato come un OAuth2 client reale con proprio client_id, non via API key o token riciclati da user.

Gestione delega degli scope: L’utente ti concede permessi specifici all’agente: accesso in sola lettura, solo alcune risorse, ecc.

Distinzione audit: I log devono distinguere tra “user ha fatto X” e “agente ha fatto X per conto user”. Se non distingui, rischi alla prossima audit SOC2 quando chiedono “chi ha eseguito questa azione?”.

Compatibilità MCP (Model Context Protocol)#

MCP sta diventando standard per far interagire agenti AI con strumenti e servizi. Se il tuo IdP supporta autenticazione OAuth per server MCP, gli agenti si autenticano nel layer corretto — non via API key o segreti condivisi.

Domande da porre#

• Supportate OAuth2 Token Exchange?
• Gli agenti possono essere clienti a sé stanti?
• I token possono trasportare info di delega (chi ha autorizzato l’agente, e scope)?
• I log audit distinguono tra azioni user e agent?
• È prevista integrazione MCP server o supporto OAuth idoneo ad agenti?

Se il fornitore non ci ha pensato, sta costruendo per il 2020. Tu stai pianificando per il 2026.

Dimensione 8: Requisiti non funzionali — Le cose che non ti fanno dormire#

Le feature vendono. L’operatività decide se rinnovi.

Performance#

• Throughput autenticazione: Può reggere 100+ richieste auth/sec nei picchi? O 1.000+?
• Latenza validazione token: Se validi JWT localmente (come dovresti), è sub-ms. Ma se serve introspezione sull’IdP, quanto è la P99 latency?
• Tetto di scala: Quanti Active User mensili massimi? Hanno track record reale alla scala che ti interessa?

Compliance#

• SOC2 Type II: Non Type I. Type II vuol dire auditato su un periodo, non su un solo snapshot. Se hanno solo Type I, chiedi quando è prevista la Type II.
• Audit log: Ogni evento di autenticazione, cambio permessi, azione admin loggata. Puoi esportarli nel tuo SIEM? Sono immutabili?
• Data residency: Puoi specificare la regione dove stanno i dati utenti? Per clienti UE non è negoziabile.

Affidabilità#

• SLA uptime: 99,9% suona bene, ma sono 8,7 ore di down annuali. 99,99% sono 52 minuti. Per l’autenticazione (la porta d’ingresso) la differenza conta.
• Failover: Che succede in caso di outage? Meccanismi fallback? Deployment multi-regione?
• Storico incident: Guarda lo status page storico. Non le promesse, ma la realtà.

Portabilità dati#

• User export: Puoi esportare tutto — utenti, metadata, membership org, ruoli? Con che formato?
• Compliance standard: Usano protocolli standard (OIDC, SCIM) che facilitano la migrazione altrove?
• No segnali di lock-in: API proprietarie, protocolli custom, formati token non standard = rischi di lock-in. Più è proprietario, più è difficile scappare.

Matrice di valutazione: Framework pratico di scoring#

Dopo aver valutato su tutte le dimensioni, serve un modo per confrontare. Ecco il framework per priorità:

P1 — Requisiti inderogabili (se non passa, scartare subito)#

P2 — Fortemente preferiti (grande sforzo ingegneristico se manca)#

P3 — Importante (da pianificare nei 12 mesi)#

P4 — Nice to have (non blocca la scelta)#

Come usarlo: Parti dal P1. Se il fornitore fallisce anche un solo criterio P1, scartalo. Poi valuta P2 e P3. Chi totalizza il miglior punteggio P2+P3 è la tua risposta.

Errori di valutazione comuni#

Abbiamo visto i team ripetere sempre gli stessi errori. Ecco come evitarli:

Errore 1: Valutare sulle feature, non sull’architettura#

Una tabella feature ti dice che esiste. Non come è realizzata. Un IdP può “supportare” le organizzazioni via org ID nei metadata utente. Sullo spreadsheet sembra ok, in produzione è un disastro.

Fix: Per ogni feature, chiedi “come è implementata?” — non solo “ce l’avete?”.

Errore 2: Ignorare la migrazione fino a dopo la selezione#

Il team sceglie il miglior IdP, inizia a integrare, poi scopre che solo con una password reset campaign si può migrare davvero. Ora o vivi una brutta esperienza o ricominci da zero.

Fix: Migrazione come primo filtro, mai come ultimo.

Errore 3: Farsi ingannare dalla demo#

Ogni demo è lucidata a festa. Mostra la happy path su database vuoto, zero edge case. In produzione hai account uniti, unicode strani nei profili, sessioni “immortali”.

Fix: Chiedi una PoC con dati veri. Importa 1.000 utenti veri e verifica i tuoi flussi reali.

Errore 4: Non coinvolgere le persone giuste#

Solo il team platform? Sceglie ciò che è più “clean”. Solo product? Sceglie ciò che integra più in fretta. Solo security? Sceglie ciò che ha più compliance.

Fix: L’evaluation team deve includere platform, product e security. Ognuno è owner di criteri P1/P2 diversi.

Errore 5: Dimenticarsi che prima o poi vorrai cambiare#

Il lock-in è reale. SDK proprietari, API custom, formati token strani: tutto rende più duro il cambio domani.

Fix: Scegli IdP basati su protocollo standard (OIDC, OAuth2, SCIM). Il tuo futuro ti ringrazierà.

FAQ#

Quanto dura tipicamente una valutazione IdP?#

Per un lavoro approfondito (inclusa PoC), conta 4-8 settimane. Se corri, rischi tutti gli errori sopra, specie quello della migrazione. Previsti: 2 settimane raccolta requisiti, 2-3 per valutazione vendor/PoC, 1-2 per allineamento stakeholder.

Dovremmo costruirci la nostra auth invece?#

Dipende dallo stadio. Meno di 10.000 utenti e niente clienti enterprise? Un auth lib semplice può andare. Ma appena servono SSO, multi-tenancy, MFA, compliance, il TCO del fai-da-te supera quello di un IdP. Abbiamo visto team mantenere auth homegrown con 2-3 ingegneri FT — sono $300-500K/anno di costo opportunità.

Differenza tra CIAM e IAM workforce?#

Customer Identity and Access Management (CIAM) è per l’utente finale del tuo prodotto — sign-up, login, gestione profilo. Workforce IAM è per i dipendenti che accedono a tool interni (es. Okta per Slack, Google Workspace ecc). Sono scelte diverse con criteri diversi. Questa guida parla di CIAM.

Quanto conta open-source vs. proprietario?#

IdP open source = trasparenza (puoi auditare il codice), portabilità (self-host se serve), community. IdP proprietari spesso UI migliori e servizi gestiti. La domanda chiave non è “open o closed” — ma “posso uscire se serve?”. Le soluzioni open-source tendono a facilitare l’export perché API e modello dati sono pubblici.

Quando l’autenticazione agenti AI va considerata P1 e non P3?#

Se già stai implementando feature AI che accedono a dati utenti (copiloti, workflow automatizzati, AI assistant), va messa a P1 subito. Se AI è sulla roadmap 6-12 mesi, resta a P3 ma pesala molto. Se AI non la stai considerando, resta P4 — ma rivedila tra 6 mesi.

Come valutare il pricing se i vendor hanno modelli diversi?#

La maggior parte degli IdP fa prezzo per MAU (Monthly Active User). Ma la definizione di MAU cambia: qualcuno conta ogni login, altri solo gli unici, altri separano i token M2M. Fatti quotare il tuo caso reale: X utenti, Y organizzazioni, Z connessioni M2M, volume auth previsto. Confronta il costo complessivo, non solo la singola unit.

Il succo#

Scegliere un identity provider è una decisione infrastrutturale, non una questione di feature. Ti stai legando a un sistema che gestirà ogni primo accesso dei tuoi utenti, ogni permission check su API, ogni audit per la compliance.

Il framework sopra copre ciò che conta davvero — non i punti marketing. Usalo per filtrare in fretta (P1), valutare a fondo (P2/P3 con PoC reale) e decidere per anni non mesi.

I team che ci riescono condividono solo una cosa: trattano l’identità come infrastruttura, non come una feature da “shippare e dimenticare”.