Perché il tuo prodotto ha bisogno di OAuth 2.0 e OIDC — Soprattutto nell'era dell'IA

Sin dall'inizio, Logto è stato costruito con una forte convinzione negli standard aperti. Abbiamo scelto di seguire protocolli come OIDC, OAuth 2.0 e SAML, non solo perché sono ampiamente utilizzati, ma perché rappresentano pratiche sicure e ben consolidate di fiducia nell'industria. La sicurezza è sempre stata una priorità per noi. Così come rimanere fedeli allo spirito dell'open source e aderire alle migliori pratiche in Gestione dell'Identità dei Clienti e all'autenticazione moderna.

Ma abbiamo anche imparato qualcosa lungo la strada:

OAuth 2.0 e OIDC non sono facili per tutti. Per i sviluppatori che sono nuovi a questi protocolli, i concetti possono sembrare estranei e a volte persino controintuitivi. Questo ha portato a vere sfide mentre lavoravamo per semplificare l'esperienza dello sviluppatore senza compromettere la sicurezza.

Due cose si sono distinte:

1. Anche se abbiamo lavorato duramente per rendere l'integrazione il più possibile fluida, c'è ancora una curva di apprendimento intorno alla comprensione dei concetti di base come i token di identità, i token di accesso e come funzionano.
2. Una domanda comune che riceviamo è: “Posso saltare il reindirizzamento sulla schermata di accesso?” Purtroppo, il reindirizzamento è una parte fondamentale di come funziona OIDC ed è necessario per un'autenticazione sicura.

Una domanda comune da parte degli utenti del nostro Discord (con il loro ID e avatar oscurati per privacy).

Ogni decisione comporta compromessi — ma a volte, una scelta che hai fatto in precedenza si rivela particolarmente preziosa man mano che emergono nuovi casi d'uso. E ora stiamo entrando in una nuova era: l'era dell'IA.

In questo articolo, esplorerò quando il tuo prodotto dovrebbe usare OIDC e OAuth 2.0, quando potrebbe non averne bisogno, e perché ho sempre sostenuto l'adozione di questi standard aperti fin dall'inizio — soprattutto se stai costruendo un vero business e scegliendo una soluzione CIAM. Spiegherò anche perché l'ascesa dell'IA rende questa decisione più importante che mai.

Cosa fa realmente OAuth 2.0 (con una semplice analogia)#

Per i lettori che non sono molto familiari con OAuth 2.0, lasciatemi prendere un momento per illustrare brevemente alcuni dei concetti di base ancora una volta — solo per rendere le cose più chiare.

OAuth 2.0 è per l'autorizzazione delegata: OAuth 2.0 è un protocollo standard del settore per l'autorizzazione — consente a un servizio di accedere a risorse a nome di un altro servizio con il consenso del proprietario della risorsa.

In uno scenario OAuth, l'utente (proprietario della risorsa) concede a un'applicazione client un accesso limitato (permessi delimitati) a un'API o server di risorse, senza condividere la propria password. OAuth definisce come richiedere e emettere token di accesso che il client può utilizzare per chiamare API protette. Questo è stato un cambiamento fondamentale rispetto ai primi tempi in cui le app potevano chiedere le tue credenziali per accedere a un altro servizio (un grave rischio per la sicurezza). Con OAuth 2.0, gli utenti approvano specifici accessi e il client ottiene un token solo con i permessi e la durata necessari – nessuna password viene scambiata, migliorando drasticamente la sicurezza.

Pensa a OAuth 2.0 come a fare il check-in in un hotel.

Tu (l'utente) sei il proprietario della stanza (i tuoi dati). Ma invece di dare a qualcuno la chiave della tua stanza (la tua password), vai alla reception e chiedi una tessera di accesso temporanea (un token di accesso) che funziona solo per il tuo ospite o amico per entrare in palestra o in piscina — non nell'intera stanza.

Il personale dell'hotel (sistema OAuth) emette questa tessera limitata con regole specifiche:

• Funziona solo per la palestra (risorsa specifica).
• È valida per un breve periodo di tempo.
• Non permette a nessuno di entrare nella tua stanza.

In questo modo, non devi cedere la tua chiave maestra — e il sistema rimane sicuro, anche se qualcun altro prende quella tessera limitata.

Diamo un'occhiata a un altro esempio. OAuth 2.0 è ampiamente utilizzato nello scenario delle registrazioni sociali.

Ipotizziamo che ti stai registrando per una nuova app come Notion, e invece di creare un nuovo nome utente e password, fai clic su “Continua con Google.”

Ecco cosa succede dietro le quinte con OAuth 2.0:

1. Veni reindirizzato alla pagina di accesso di Google, dove effettui il login (se non lo sei già).

2. Google chiede:

   “Permetti a questa app di visualizzare il tuo profilo di base e l'indirizzo email?”

3. Clicchi “Consenti”, e Google invia all'app un token di accesso.

4. L'app usa quel token per:

   • Confermare la tua identità (tramite la tua email e le informazioni del profilo).
   • Creare o farti accedere a un account — senza mai vedere la tua password di Google.

Cosa fa realmente OIDC (con una semplice analogia)#

Ora diamo un'occhiata a OIDC — uno standard più recente e avanzato. OpenID Connect mira all'Identità e all'Autenticazione: è uno strato di autenticazione costruito sopra OAuth 2.0. Mentre OAuth 2.0 da solo non dice all'applicazione chi è l'utente (si tratta solo di token di accesso e ambiti), OIDC aggiunge un modo standard per gestire l'accesso degli utenti e l'identità.

Utilizzando OIDC, il server di autorizzazione funge anche da OpenID Provider (un Identity Provider) che autentica l'utente e rilascia un ID token contenente informazioni sull'utente (le “rivendicazioni di identità”).

In breve, OAuth 2.0 risponde “Questo client può accedere a questa risorsa?” e OIDC risponde “Chi è l'utente che ha appena effettuato l'accesso?”. Insieme, consentono alla tua app di verificare l'identità dell'utente e poi utilizzare token autorizzati per accedere alle API per conto dell'utente.

Usiamo l'analogia dell'hotel per comprendere meglio OAuth 2.0 vs. OIDC ancora una volta.

Immagina di fare il check-in in un hotel.

• OAuth 2.0 è come chiedere all'hotel di lasciare che il tuo amico usi la palestra e la piscina a tuo nome.

  Vai alla reception, dai il permesso, e l'hotel dà al tuo amico un pass per ospiti.

  All'hotel non importa chi sia l'amico — solo che siano autorizzati a usare le strutture.

  👉 Questo è OAuth: “Questa app può accedere ad alcuni dei miei dati o servizi.”

• OIDC è come chiedere all'hotel di controllare chi è la persona prima di dare loro accesso.

  Quindi il tuo amico mostra anche un documento di identità — e ora l'hotel conosce il loro nome, lo stato, e che sono un ospite verificato.

  👉 Questo è OIDC: “Ecco chi è l'utente e ora hanno effettuato l'accesso.”

Come Logto utilizza OAuth 2.0 e OpenID Connect (OIDC)#

Le caratteristiche di autenticazione principali di Logto sono costruite su OIDC (OpenID Connect)#

Nel suo nucleo, Logto è un provider OpenID Connect (OIDC) — uno standard costruito su OAuth 2.0 che si concentra su una sicura e moderna autenticazione degli utenti. Logto è una soluzione CIAM professionale, dove le identità sono i blocchi di base che gestiamo.

Abbiamo progettato Logto con la sicurezza come fondamento. Ciò significa applicare PKCE di default, bloccando flussi non sicuri come il flusso implicito, e facendo affidamento sul reindirizzamento per gestire gli accessi in modo sicuro.

Perché il reindirizzamento?#

OIDC è progettato per l'autenticazione basata su browser. Non è solo una scelta tecnica — riguarda l'offrire agli utenti un'esperienza sicura e coerente su piattaforme diverse. Reindirizzare l'utente al provider di identità (come Logto, Google o Microsoft) aiuta a rendere possibile questo.

Ecco come appare il flusso tipico:

1. L'utente clicca su “Accedi”

   → La tua app li invia alla pagina di accesso di Logto.

2. Accedono in modo sicuro

   → È qui che avvengono cose come MFA, biometria o registrazioni sociali.

3. Logto li rimanda indietro

   → Insieme a un token sicuro o un codice di autorizzazione.

4. La tua app completa l'accesso

   → Il token è verificato e l'utente ha effettuato l'accesso.

Questo modello può sembrare semplice, ma porta potenti benefici:

• La tua app non gestisce direttamente le credenziali — il che significa meno rischi.
• È più facile aggiungere funzionalità come MFA senza cambiare il codice dell'app.
• Funziona alla grande anche per mobile:
  • iOS usa ASWebAuthenticationSession
  • Android usa Custom Tabs

E se il tuo prodotto si estende su più app, il reindirizzamento consente il single sign-on — gli utenti accedono una volta e si spostano tra le app senza attriti.

Logto non supporta la raccolta diretta delle password nella tua app. Questo è intenzionale. Il flusso ROPC non è raccomandato per le migliori pratiche di sicurezza OAuth 2.0 per buone ragioni — è meno sicuro e più difficile da scalare in modo sicuro.

Logto è anche un provider di OAuth 2.0/OIDC (Identity Provider)#

Logto è più di un semplice server di autenticazione — è un completo OAuth 2.0, OpenID Connect (OIDC) e Identity Provider (IdP). Ciò significa che può gestire in modo sicuro le identità degli utenti e emettere token a cui altre applicazioni possono affidarsi.

Oltre ad alimentare esperienze di accesso per le tue app, Logto supporta anche integrazioni con applicazioni di terze parti, consentendo a servizi esterni di fare affidamento su Logto come fonte di identità.

Cosa significa in pratica?

Come Identity Provider (IdP), Logto gestisce la verifica degli utenti, gestisce le credenziali e emette token di autenticazione. Una volta che un utente effettua l'accesso, Logto può consentire loro di accedere a diverse app — anche di altri fornitori — senza dover effettuare nuovamente l'accesso. È lo stesso concetto dietro “Accesso con Google” o “Accesso con Microsoft”.

Ci sono due tipi di applicazioni in questo contesto:

• App di prima parte: App che costruisci e controlli completamente, integrate direttamente con Logto.
• App di terze parti: Servizi esterni costruiti da partner o sviluppatori al di fuori della tua organizzazione.

Logto consente ai tuoi utenti di accedere a queste app di terze parti utilizzando i propri account Logto esistenti — proprio come gli utenti aziendali accedono a strumenti come Slack con le proprie credenziali Google Workspace. Ciò ti consente di:

• Offrire single sign-on (SSO) nel tuo ecosistema.
• Costruire una piattaforma aperta, dove sviluppatori di terze parti possono aggiungere “Accedi con Logto” alle loro app.

Quando hai veramente bisogno di OAuth 2.0 e OIDC?#

1. Se usavi precedentemente Auth0 (o simili): Auth0 è già un provider OAuth 2.0 e OIDC. Gestisce l'accesso degli utenti, l'emissione dei token e si integra con le tue API o app.
2. Autorizzazione M2M: Server-to-server (flusso delle credenziali client) Le macchine (o i servizi backend) devono comunicare in modo sicuro senza un utente.
3. Device flow: Smart TV, console, dispositivi IoT: Dispositivi come TV o stampanti devono autenticare un utente. Il flusso dei dispositivi è parte dell'OIDC.
4. Hai bisogno di interazioni: Non stai solo autenticando gli utenti — stai creando un ecosistema dove app esterne, partner o agenti possono integrarsi con la tua piattaforma e accedere ai dati degli utenti in modo sicuro.

Perché OAuth e OIDC sono più importanti che mai nell'era IA#

Nell'era IA, stiamo assistendo a un'impennata delle necessità di integrazione e accesso — specialmente in aree come agenti autonomi, dispositivi intelligenti e comunicazioni sistema-sistema. Queste tendenze rendono OAuth 2.0 e OIDC più importanti che mai. Ecco alcuni esempi:

1. Server MCP remoti

   Costruisci un server MCP (Model Context Protocol) remoto e vuoi che agenti di terze parti si connettano a esso. Questi agenti hanno bisogno di un accesso sicuro per richiedere contesto, eseguire azioni e scambiare dati — il tutto senza compromettere la fiducia dell'utente. OAuth fornisce il meccanismo per delegare l'accesso in sicurezza.

2. Aprire il tuo prodotto alle integrazioni

   Gestisci i tuoi servizi business — ad esempio un tool di gestione progetti o una piattaforma clienti — e vuoi consentire ad altri prodotti o agenti di integrarsi con esso. Ciò potrebbe significare estrarre dati, attivare workflow o incorporare le tue funzionalità in altri ambienti. OAuth 2.0/OIDC abilita un controllo dell'accesso basato su token senza condividere le credenziali utente.

3. Costruire il tuo agente

   Stai creando un agente o assistente IA e vuoi che interagisca con altre app e server MCP — pianificando incontri, inviando email, pubblicando aggiornamenti o interrogando dati. Queste azioni richiedono un accesso autenticato e sicuro ai servizi di terze parti. OAuth 2.0 è il modo in cui il tuo agente ottiene l'autorizzazione per agire a nome dell'utente.

4. L'ascesa dei dispositivi intelligenti

   Dispositivi hardware come traduttori IA o strumenti per prendere appunti intelligenti stanno diventando più capaci grazie agli LLM. E con costi più bassi e prestazioni più elevate, sempre più di questi dispositivi stanno arrivando sul mercato. Questi dispositivi spesso necessitano di un modo per autenticare gli utenti e accedere ai servizi basati sul cloud — soprattutto con interfacce di input limitate. È qui che flussi come l'authorization flow dei dispositivi OAuth e la validazione dell'identità basata su OIDC diventano fondamentali.

Quando potresti non aver bisogno di OAuth 2.0/OIDC#

Ovviamente, ci sono casi in cui potresti non aver bisogno di OAuth 2.0 o OIDC — almeno non subito. In altre parole, se il tuo caso d'uso attuale è semplice o completamente autonomo, questi protocolli potrebbero non portare un valore immediato.

Tuttavia, man mano che il tuo prodotto cresce o il tuo ecosistema si espande, la necessità di OAuth 2.0 e OIDC spesso diventa molto più evidente a lungo termine.

1. App interne e semplici

   Se la tua app è utilizzata solo da un piccolo team all'interno di un'azienda e non deve integrarsi con servizi di terze parti o esporre API, un sistema di autenticazione di base con nome utente-password (ad esempio, sessioni con cookie) potrebbe essere sufficiente.

2. Nessuna autenticazione utente necessaria

   Se il tuo prodotto non ha account utente o funzionalità consapevoli dell'identità — come un sito di contenuto pubblico o uno strumento server-to-server con chiavi API statiche — OIDC non è necessario.

3. Nessun accesso delegato richiesto

   OAuth è utile quando hai bisogno che gli utenti autorizzino la tua app ad accedere ai loro dati in un altro sistema (ad esempio, Google Drive). Se non ti stai integrando con API di terze parti o costruendo workflow multiservizio, OAuth aggiunge complessità con poco valore.

4. Ambiente singolo, rischio minimo

   Per prototipi in fase iniziale, MVP, o strumenti di test interni dove semplicità e velocità superano le esigenze di sicurezza, potresti ritardare l'implementazione di OAuth/OIDC fino a più tardi.

Considerazioni finali sulla scelta della giusta strategia di autenticazione#

Potresti non aver bisogno di OAuth 2.0 o OIDC subito — e va bene così. Nelle prime fasi, soluzioni semplici spesso fanno il lavoro. Ma man mano che il tuo prodotto cresce, come gli agenti e l'IA diventano più integrati nel modo in cui costruiamo, e come il tuo ecosistema si apre a partner e terze parti, l'autenticazione sicura e standardizzata diventa meno un extra di lusso e più una necessità.

Invece di dover correre ai ripari più tardi, val la pena gettare le basi ora. Adottare OAuth 2.0 e OIDC non riguarda solo la risoluzione dei problemi di oggi — è un modo per essere pronti per ciò che viene dopo.