OAuth 2.0 e OpenID Connect sono due standard fondamentali per la gestione delle identità e delle autorizzazioni nelle applicazioni web, nelle API e nei servizi distribuiti. Sebbene vengano spesso utilizzati insieme, risolvono problemi differenti: OAuth 2.0 definisce un framework per delegare l'accesso a risorse protette, mentre OpenID Connect (OIDC) aggiunge un livello di autenticazione che permette a un'applicazione di verificare l'identità dell'utente. Comprendere la distinzione tra questi protocolli è essenziale per progettare sistemi di Single Sign-On, integrazioni con identity provider esterni e architetture applicative che richiedono un controllo granulare degli accessi.

OAuth 2.0: delegare l'accesso alle risorse

OAuth 2.0 consente a un'applicazione client di ottenere un'autorizzazione limitata per accedere a una risorsa protetta senza dover ricevere direttamente le credenziali dell'utente. In un'architettura tipica intervengono il resource owner, cioè il soggetto che controlla la risorsa, il client che richiede l'accesso, l'authorization server che gestisce il rilascio delle autorizzazioni e il resource server che espone i dati o le funzionalità protette. L'authorization server emette un access token che il client presenta al resource server per dimostrare di possedere l'autorizzazione necessaria. Il token può incorporare informazioni sulle autorizzazioni concesse oppure essere un riferimento opaco che il server deve verificare attraverso i meccanismi previsti dall'implementazione.

Un aspetto importante è che OAuth 2.0 non definisce, da solo, un protocollo standard completo per autenticare l'utente e comunicare alla applicazione la sua identità. Un access token autorizza l'accesso a determinate risorse, ma non deve essere interpretato automaticamente come prova dell'identità dell'utente che ha avviato il flusso. Questa distinzione è rilevante nelle applicazioni che utilizzano un unico provider per consentire sia l'accesso sia l'interazione con API aziendali: l'autenticazione deve essere gestita con un protocollo appropriato, mentre l'autorizzazione deve limitare le operazioni che il client può eseguire.

OpenID Connect: aggiungere l'autenticazione a OAuth 2.0

OpenID Connect estende OAuth 2.0 introducendo un livello standardizzato per l'autenticazione. L'applicazione può così ottenere informazioni sull'identità dell'utente attraverso un ID token, normalmente un JSON Web Token (JWT) firmato dall'identity provider. Il token contiene claim standardizzati, come l'identificativo dell'emittente, il destinatario previsto, il momento di emissione e l'identificativo del soggetto autenticato. In base agli scope richiesti e alle autorizzazioni concesse, possono essere rese disponibili anche informazioni aggiuntive sul profilo dell'utente.

La validazione dell'ID token richiede controlli rigorosi. L'applicazione deve verificare la firma utilizzando le chiavi attendibili dell'identity provider, controllare il valore di iss per accertare l'identità dell'emittente e verificare aud per assicurarsi che il token sia destinato al client corretto. Devono inoltre essere controllati la scadenza tramite exp, gli eventuali vincoli temporali aggiuntivi e il valore nonce, quando previsto dal flusso, per collegare la risposta di autenticazione alla richiesta originaria e mitigare attacchi di replay. La verifica non deve basarsi soltanto sulla decodifica del JWT, perché leggere il contenuto di un token non equivale a verificarne l'autenticità.

OpenID Connect introduce anche l'endpoint UserInfo, che permette di recuperare claim relativi all'utente presentando un access token valido, e definisce metadati di discovery attraverso i quali il client può individuare gli endpoint e le informazioni crittografiche dell'identity provider. Queste funzionalità riducono la necessità di configurazioni manuali e favoriscono l'interoperabilità tra applicazioni e sistemi di identità differenti.

Authorization Code Flow e PKCE

Per le applicazioni moderne, il flusso generalmente raccomandato è Authorization Code Flow, spesso combinato con PKCE (Proof Key for Code Exchange). Il client avvia una richiesta verso l'authorization server, che autentica l'utente e, dopo il consenso o l'applicazione delle policy previste, restituisce un authorization code attraverso il redirect URI registrato. Il client scambia quindi il codice con i token attraverso l'endpoint di token dell'authorization server. Il codice è temporaneo e utilizzabile secondo le condizioni stabilite dal protocollo; non deve essere trattato come un token di accesso.

PKCE aggiunge una protezione contro l'intercettazione o l'utilizzo fraudolento del codice di autorizzazione. Il client genera un valore casuale chiamato code_verifier e ne calcola una trasformazione, normalmente mediante S256, denominata code_challenge. La richiesta iniziale contiene il challenge, mentre nello scambio del codice il client presenta il verifier originale. L'authorization server verifica la corrispondenza tra i due valori e rifiuta lo scambio se il controllo fallisce. Questo meccanismo è particolarmente importante per le applicazioni native e per i client pubblici, che non possono mantenere un segreto statico in modo affidabile. PKCE è comunque utile anche in altri contesti e viene comunemente adottato nelle implementazioni moderne.

I redirect URI devono essere registrati e verificati con precisione per evitare che codici o token vengano inviati a destinazioni non autorizzate. È necessario utilizzare HTTPS negli ambienti di produzione, gestire correttamente il parametro state per correlare la risposta al flusso avviato e applicare le protezioni previste dal tipo di applicazione. I client pubblici, come le applicazioni mobile o quelle eseguite interamente nel browser, non devono fare affidamento su un client secret inserito nel codice distribuito, perché tale segreto può essere estratto.

Access token, ID token e refresh token: differenze operative

La gestione dei token è uno degli aspetti più delicati nell'implementazione di OAuth 2.0 e OpenID Connect. L'access token viene presentato al resource server per accedere a una risorsa protetta e dovrebbe avere ambito, durata e privilegi coerenti con le operazioni richieste. L'ID token, invece, comunica al client le informazioni necessarie per verificare l'autenticazione dell'utente e non deve essere utilizzato come sostituto dell'access token nelle chiamate alle API. Confondere i due token può causare errori architetturali e verifiche di sicurezza insufficienti.

Il refresh token permette, quando previsto, di ottenere nuovi access token senza ripetere immediatamente l'intero processo di autenticazione. La sua gestione richiede particolare attenzione perché può avere una durata superiore rispetto all'access token e consente di prolungare l'accesso. È opportuno proteggerlo in modo adeguato, limitarne l'utilizzo ai client autorizzati e adottare, quando supportata, la rotazione dei refresh token con rilevamento del riutilizzo. Le modalità di conservazione dipendono dal tipo di applicazione: un backend può mantenere i token in un archivio protetto sul server, mentre un'applicazione browser deve valutare attentamente i rischi legati a JavaScript, attacchi XSS e persistenza delle credenziali nel client.

Anche la durata dei token deve essere definita sulla base del rischio e delle esigenze operative. Token di breve durata riducono la finestra di esposizione in caso di compromissione, ma possono aumentare la frequenza dei rinnovi. La revoca e l'invalidazione dipendono dal tipo di token e dall'architettura adottata: un JWT autonomamente verificabile può continuare a essere accettato fino alla scadenza, a meno che il sistema non preveda controlli aggiuntivi, mentre i token opachi possono essere verificati attraverso un servizio centrale. Non esiste quindi un'unica strategia valida per tutti i sistemi, ma una progettazione deve considerare durata, revoca, rotazione, logging e protezione dei segreti.

Scope, claim e controllo delle autorizzazioni

Gli scope definiscono l'ambito dell'autorizzazione richiesta dal client. Un'applicazione può, ad esempio, ottenere il permesso di leggere determinate informazioni senza ricevere automaticamente il diritto di modificarle o cancellarle. In OpenID Connect lo scope openid identifica una richiesta OIDC, mentre valori come profile ed email possono richiedere claim aggiuntivi sull'utente, nei limiti delle autorizzazioni concesse. Gli scope non sostituiscono però la logica di autorizzazione interna: il backend deve verificare che il soggetto e il client siano effettivamente autorizzati a eseguire l'operazione richiesta sulla specifica risorsa.

La gestione dei permessi può combinare scope, ruoli applicativi, attributi dell'utente e policy contestuali. Per esempio, un token può consentire l'accesso a un'API di gestione ordini, ma l'applicazione deve comunque verificare che l'utente possa consultare l'ordine richiesto e che l'operazione sia compatibile con il suo ruolo. Anche i claim devono essere interpretati in base all'emittente, al destinatario e al contesto per cui sono stati rilasciati. Non è corretto assumere che ogni informazione contenuta in un token sia automaticamente attendibile per qualsiasi servizio o che la presenza di un ruolo generico autorizzi tutte le operazioni.

OAuth 2.0 e OpenID Connect nelle architetture aziendali

In un'infrastruttura aziendale, OAuth 2.0 e OpenID Connect possono essere integrati con sistemi di Single Sign-On, directory utenti, applicazioni gestionali, portali web e API interne. L'identity provider centralizza l'autenticazione e applica le policy previste, mentre i servizi applicativi verificano i token e applicano le autorizzazioni relative alle proprie risorse. Questa separazione consente di ridurre la duplicazione della logica di autenticazione, semplificare l'integrazione di nuove applicazioni e applicare controlli uniformi, purché ogni client e ogni servizio siano configurati correttamente.

La scelta dell'architettura deve considerare il tipo di client, la presenza di un backend, la necessità di accesso alle API, i requisiti di Single Sign-On e la gestione del ciclo di vita dei token. Le applicazioni server-side possono mantenere le credenziali di sessione e i token lato backend, mentre le applicazioni native e le SPA richiedono una valutazione specifica della gestione dei token e dell'esposizione nel client. In presenza di più servizi, è inoltre importante stabilire come vengono verificati i token, come vengono distribuite le chiavi pubbliche e come si gestiscono la rotazione delle chiavi, gli errori di autenticazione e gli eventi di sicurezza.

L'adozione corretta di OAuth 2.0 e OpenID Connect non consiste semplicemente nel collegare un pulsante di accesso a un provider esterno. Richiede la definizione dei flussi supportati, la validazione dei token, la protezione delle credenziali, la configurazione dei redirect URI, la gestione delle sessioni e l'applicazione di autorizzazioni coerenti con le risorse esposte. Una progettazione rigorosa riduce i rischi di furto dei token, accesso non autorizzato e configurazioni errate, migliorando al tempo stesso l'interoperabilità e la manutenibilità delle applicazioni aziendali.