OAuth dentro una VPN: quali tratti richiedono ancora TLS

L’instradamento privato decide chi raggiunge il server; le regole di trasporto di OAuth decidono come viaggia ogni messaggio. Un browser, un server di autorizzazione, un endpoint di token e un server di risorse possono stare tutti dietro la stessa VPN e scambiarsi comunque messaggi su tratti diversi. Ogni tratto ha il proprio requisito di trasporto, e la VPN non ne allenta nessuno. Il confine della VPN e il confine del protocollo sono due linee diverse.

La decisione è più semplice se smettete di chiedere se la rete è fidata e iniziate a chiedere quale scambio attraversa quale confine.

Decidete per tratto, non per rete

Annotate gli endpoint separatamente: endpoint di autorizzazione, endpoint di token, URI di reindirizzamento, URL del server di risorse, punto di terminazione TLS e gateway VPN. Poi indicate quale parte avvia ogni richiesta e dove va la risposta.

Una VPN che termina a un gateway cifra il segmento fino a quel gateway. La richiesta può proseguire come HTTP semplice dietro di esso, e quel tratto rimanente non è diventato HTTPS perché un segmento precedente è stato cifrato. Proprio quella continuazione è il tratto che interessa al protocollo. Cifrare il primo salto non rende sicuro il secondo salto.

Il trasporto porta anche un controllo dell’identità del servizio. Il browser convalida il certificato per l’URL dell’applicazione; una VPN non esegue quella convalida per conto del browser e non rende accettabile un endpoint non convalidato. Il certificato nomina l’endpoint che il client ritiene di chiamare. Un tunnel verso un gateway non rinomina quell’endpoint né lo convalida.

La risposta di autorizzazione e l’URI di reindirizzamento

La migliore pratica di sicurezza attuale di OAuth vieta di trasmettere risposte di autorizzazione su connessioni non cifrate. Ciò comprende il reindirizzamento che riporta al client il codice di autorizzazione o i token, non solo la richiesta iniziale.

La stessa guida non consente URI di reindirizzamento HTTP, salvo il caso di loopback specificato per i client nativi. Un nome host interno non crea una nuova eccezione, e un nome DNS che si risolve solo dentro la VPN resta un URL HTTP se lo schema lo dice. Controllate lo schema nell’URI registrato, non solo il nome host.

Registrate l’URI di reindirizzamento HTTPS esatto presso il server di autorizzazione e mantenete attiva la convalida dei certificati sul client. Una scorciatoia di sviluppo che sopprime il requisito HTTPS produce un flusso che si comporta diversamente dalla configurazione di produzione che dovrebbe modellare.

L’endpoint di token e le richieste con token di portatore

La richiesta di token porta credenziali o un codice che può essere scambiato con l’accesso. Inviarla su un tratto non protetto espone materiale di cui il server di risorse si fiderà in seguito, anche se la rete circostante è privata. Un proxy che può leggere la richiesta può leggere anche la credenziale che porta.

Per le richieste di risorse con token di portatore, RFC 6750 considera TLS obbligatorio da implementare e usare per quella specifica. Definire fidato la sottorete dell’ufficio non è l’eccezione di protocollo generale di cui ha bisogno un impiego di portatore in testo in chiaro.

Usate gli URL sicuri documentati degli endpoint per entrambi i tratti. Se una libreria rifiuta di chiamare un endpoint di token HTTP, quel rifiuto è la specifica che funziona, non un difetto di configurazione da aggirare. Registrate quell’URL nella configurazione del client invece di ricavarlo a runtime.

Dove termina TLS e cosa lascia

Se TLS termina a un frontend autorizzato, nominate quel frontend ed esaminate il percorso da esso all’applicazione. Il frontend diventa responsabile dell’inoltro, della fiducia e della riservatezza sul segmento rimanente, e l’architettura supportata del servizio dovrebbe descrivere quella disposizione.

Una VPN altrove nel percorso non risolve quelle responsabilità. Non vi dice nemmeno se l’URL dell’applicazione che il browser vede corrisponde al certificato che il frontend presenta.

Per un impiego interno, annotate il punto di terminazione e l’identità che presenta. Un frontend che termina TLS con un certificato per un altro nome crea un avviso del browser che gli operatori spesso sopprimono invece di correggere.

L’eccezione di loopback nativo è stretta

L’eccezione di reindirizzamento in loopback riguarda un callback sul dispositivo dell’utente stesso, dove il client e il browser condividono quel dispositivo. Quella disposizione appartiene a un callback su un solo dispositivo e non autorizza a servire un normale server di autorizzazione o un’API con token su HTTP verso una sottorete d’ufficio.

Mantenete l’eccezione limitata al tipo di client e al callback che descrive. Applicarla a un’applicazione web, a un servizio interno condiviso o a un URI di reindirizzamento su un altro host cambia l’impiego, non l’eccezione.

Provate il flusso reale a ogni confine e confrontatelo con il tipo di client. Un reindirizzamento funzionante non dice nulla sul fatto che ogni tratto che ha portato un token abbia usato la protezione richiesta, e un’icona VPN verde non dice nulla sullo schema della richiesta successiva.