Perché dovresti deprecare il tipo di concessione delle Credenziali Password del Proprietario della Risorsa (ROPC)

Introduzione#

Il tipo di concessione delle Credenziali Password del Proprietario della Risorsa (ROPC) noto anche come tipo di concessione della password è un flusso di OAuth 2.0 che permette a un'applicazione di scambiare il nome utente e la password di un utente con un token di accesso. È stato introdotto per la prima volta nella specifica OAuth 2.0 come un modo per supportare applicazioni legacy come l'autenticazione di base HTTP o applicazioni native legacy che non potevano utilizzare flussi di token OAuth più sicuri.

Tuttavia, il tipo di concessione ROPC comporta numerosi rischi per la sicurezza ed è stato indicato come NON DEVE essere utilizzato nelle migliori pratiche di sicurezza OAuth 2.0.

Di recente, abbiamo ricevuto diverse domande dai nostri clienti che richiedevano indicazioni o supporto per implementare il tipo di concessione ROPC. In questo post, spiegheremo perché dovresti evitare di utilizzare il tipo di concessione ROPC, soprattutto per le tue nuove applicazioni.

Tipo di concessione ROPC vs. flusso del codice di autorizzazione#

Come funziona il tipo di concessione ROPC#

Il tipo di concessione ROPC è un flusso semplice che scambia il nome utente e la password dell'utente con un token di accesso. L'applicazione client raccoglie direttamente le credenziali dell'utente e le invia direttamente al server di autorizzazione. Il server di autorizzazione quindi convalida le credenziali e rilascia un token di accesso al client.

Come funziona il flusso del codice di autorizzazione#

Al contrario, il flusso del codice di autorizzazione è il flusso OAuth 2.0 raccomandato per le applicazioni web. Involge diversi passaggi e reindirizzamenti tra l'applicazione client, il server di autorizzazione e il browser dell'utente. Il flusso del codice di autorizzazione è più sicuro perché non espone le credenziali dell'utente all'applicazione client.

La principale differenza tra il tipo di concessione ROPC e il flusso del codice di autorizzazione è che ROPC espone le credenziali dell'utente all'applicazione client, mentre il flusso del codice di autorizzazione no. Le credenziali dell'utente devono essere mantenute confidenziali all'interno del server di autorizzazione. Ogni volta che un'applicazione client richiede una risorsa per conto dell'utente, dovrebbe reindirizzare l'utente al server di autorizzazione per autenticare e autorizzare l'applicazione client. Ciò mantiene un minimo di dati di autorizzazione sul lato dell'applicazione client.

Rischi per la sicurezza del tipo di concessione ROPC#

1. Esposizione delle credenziali dell'utente#

Come menzionato in precedenza, il tipo di concessione ROPC espone le credenziali dell'utente all'applicazione client. Questo è un rischio significativo per la sicurezza perché l'applicazione client può memorizzare o registrare le credenziali dell'utente e ottenere una ri-autorizzazione senza che l'utente ne sia a conoscenza.

Soprattutto per un'applicazione client pubblica come un'applicazione mobile o un'applicazione a pagina singola, l'applicazione client può essere facilmente iniettata o sottoposta a reverse engineering per estrarre le credenziali dell'utente. Né un'applicazione mobile né un'applicazione a pagina singola che gira nel browser dell'utente possono mantenere segreti in modo confidenziale. Pertanto, non possono autenticare l'utente senza esporre le credenziali dell'utente.

Anche se il proprietario della risorsa ha una relazione di fiducia con l'applicazione client, l'applicazione client svolge un ruolo di intermediario (man-in-the-middle) nell'intero processo di autenticazione, potrebbe essere compromessa da un attore malintenzionato. Un attore malintenzionato può rubare le credenziali dell'utente e impersonare l'utente per accedere alle sue risorse.

Ci sono diversi modi per rubare le credenziali dell'utente, basati sulla postura di sicurezza dell'applicazione client, come keylogger, attacchi di phishing o malware. Senza menzionare che le credenziali del cliente sono trasmesse sulla rete ad ogni richiesta di autorizzazione. Ciò aumenta ulteriormente il rischio di intercettazione delle credenziali.

Immagina se hai più applicazioni che usano il tipo di concessione ROPC, il rischio potenziale di esposizione delle credenziali è moltiplicato.

2. ROPC non supporta il consenso dell'utente#

Il tipo di concessione ROPC non supporta il consenso dell'utente. Quando l'applicazione client raccoglie direttamente le credenziali dell'utente, l'utente non ha la possibilità di rivedere e approvare l'accesso dell'applicazione client alle sue risorse. Questo è una violazione della privacy e della fiducia dell'utente.

Gli utenti dovrebbero avere il diritto di decidere quali applicazioni client possono accedere alle loro risorse e per quanto tempo. Soprattutto per le applicazioni di terze parti, un meccanismo di consenso dell'utente è essenziale per proteggere i dati del proprietario della risorsa e per conformarsi a regolamenti sulla protezione dei dati come il GDPR.

3. ROPC non supporta l'autenticazione multi-fattore#

L'autenticazione multi-fattore (MFA) è un'implementazione di sicurezza che richiede all'utente di fornire due o più fattori di verifica per accedere alle proprie risorse. Aggiunge un ulteriore livello di sicurezza al processo di autenticazione. Il tipo di concessione ROPC non supporta MFA. Invece, limita il processo di autenticazione a un singolo fattore, e la richiesta di token si basa solo sulle credenziali dell'utente. È impossibile implementare meccanismi di autenticazione basati su sfide come SMS OTP, email OTP o WebAuthn con il tipo di concessione ROPC.

ROPC non è compatibile con le applicazioni moderne#

Il tipo di concessione ROPC è stato progettato per supportare applicazioni legacy che non possono supportare moderni sistemi IAM di Single Sign-On (SSO) o identità federate.

1. ROPC non è compatibile con SSO#

Il Single Sign-On (SSO) è un'architettura di autenticazione moderna che consente agli utenti di effettuare il login una sola volta e accedere a più applicazioni senza sforzo.

Un IdP centralizzato svolge un ruolo cruciale nell'architettura SSO. Gestisce la sessione di autenticazione dell'utente e rilascia token alle applicazioni client. Le applicazioni client non hanno bisogno di raccogliere direttamente le credenziali dell'utente, e le credenziali dell'utente sono mantenute confidenzialmente all'interno dell'IdP.

Il tipo di concessione ROPC non supporta SSO. Richiede all'applicazione client di raccogliere direttamente le credenziali dell'utente, il che interrompe l'architettura della SSO. Non è compatibile con sistemi SSO moderni come OpenID Connect (OIDC) o SAML.

2. ROPC non è compatibile con identità federate#

Simile all'architettura SSO, le identità federate consentono agli utenti di utilizzare la propria identità esistente per accedere a più applicazioni di terze parti. Un utente può collegare più account social come Google, Facebook o Twitter a un IdP centralizzato e utilizzare questi account social per autenticarsi con le applicazioni client. Tutte le identità federate sono gestite dall'IdP e le applicazioni client non sono a conoscenza dei dettagli dell'autenticazione dell'utente.

Il tipo di concessione ROPC, invece, richiede all'applicazione client di raccogliere direttamente le credenziali dell'utente. Ciò limita la capacità dell'applicazione client di supportare identità federate e espone i dati dell'identità dell'utente all'applicazione client.

Conclusione#

Il tipo di concessione delle Credenziali Password del Proprietario della Risorsa (ROPC) è un flusso legacy di OAuth 2.0 che comporta significativi rischi per la sicurezza e dovrebbe essere deprecato. Espone le credenziali dell'utente all'applicazione client, non supporta meccanismi di sicurezza moderni come MFA o SSO. Si raccomanda vivamente di evitare di utilizzare il tipo di concessione ROPC per le tue applicazioni. Se hai sistemi di autenticazione legacy che si basano sul tipo di concessione ROPC, prendi in considerazione la migrazione a flussi OAuth 2.0 più sicuri come il flusso del codice di autorizzazione o il flusso delle credenziali del client.

Contattaci se hai bisogno di aiuto nell'integrare un servizio di autenticazione e autorizzazione sicuro per gli utenti nelle tue applicazioni, o nel migrare da un sistema di autenticazione basato su password legacy a un flusso OAuth 2.0 più sicuro. Siamo qui per aiutarti a costruire applicazioni sicure e moderne.