La risposta alla tua domanda può essere a livello di codice, a livello di protocollo o a livello di architettura. Cercherò di sintetizzare qui la maggior parte dei problemi a livello di protocollo poiché ciò è di solito fondamentale nell'analisi dei pro e dei contro. Tieni presente che OAuth2 è molto più delle credenziali della password del proprietario della risorsa che, secondo le specifiche, esistono per "motivi legacy o di migrazione", sono considerate "a rischio più elevato rispetto ad altri tipi di concessione" e la specifica afferma esplicitamente che i client e i server di autorizzazione "DOVREBBE ridurre al minimo l'uso di questo tipo di sovvenzione e utilizzare altri tipi di sovvenzioni quando possibile".
Ci sono ancora molti vantaggi nell'utilizzo di ROPC rispetto all'autenticazione di base, ma prima di approfondire, capiamo la differenza di protocollo di base tra OAuth2 e l'autenticazione di base. Per favore, abbi pazienza mentre spiego questi e arriverà a ROPC più tardi.
Flussi di autenticazione dell'utente
Esistono quattro ruoli definiti nella specifica OAuth2. Con esempi, sono:
- Proprietario della risorsa: l'utente che ha accesso ad alcune risorse, ad esempio nel tuo caso, utenti diversi possono avere un livello di accesso diverso all'API REST;
- Il client: di solito l'applicazione che l'utente sta utilizzando e necessita dell'accesso alla risorsa per fornire servizi all'utente;
- Server di risorse: l'API REST nel tuo caso; e
- Server di autorizzazione: il server a cui vengono presentate le credenziali dell'utente e che autentica l'utente.
Quando viene eseguita un'applicazione client, viene concesso l'accesso alle risorse in base all'utente. Se un utente dispone dei privilegi di amministratore, le risorse e le operazioni disponibili per l'utente nell'API REST potrebbero essere molto più di un utente senza privilegi di amministratore.
OAuth2 consente inoltre la possibilità di utilizzare un singolo server di autorizzazione con più client e per più risorse. Ad esempio, un server di risorse può accettare l'autenticazione dell'utente con Facebook (che può fungere da server di autorizzazione in tal caso). Pertanto, quando l'utente esegue un'applicazione (ovvero il client), invia l'utente a Facebook. L'utente digita le proprie credenziali su Facebook e il client riceve un "token" che può presentare al server delle risorse. Il server delle risorse esamina il token e lo accetta dopo aver verificato che Facebook lo ha effettivamente emesso e consente all'utente di accedere alla risorsa. In questo caso, il client non vede mai le credenziali dell'utente (ovvero le credenziali di Facebook).
Supponiamo che tu stia gestendo le identità del tuo utente (e disponga di un server di autorizzazione) invece di Facebook, che garantisce già token al tuo client. Ora, supponiamo che tu abbia anche un partner e desideri consentire alla sua applicazione (client) di accedere all'API REST. Con l'autenticazione di base (o persino ROPC), l'utente fornirà le credenziali a quel client che lo invierà al server di autorizzazione. Il server di autorizzazione fornirà quindi un token che può essere utilizzato dal client per accedere alle risorse. Sfortunatamente, questo significa che le credenziali dell'utente sono ora visibili anche a quel client. Tuttavia, non si desidera che l'applicazione di un partner (che potrebbe essere esterna alla propria organizzazione) sia a conoscenza della password di un utente. Questo è un problema di sicurezza ora. Al fine di raggiungere tale obiettivo,
Pertanto, con OAuth2, idealmente non si userebbe ROPC in tali casi piuttosto che usarne uno diverso, come il flusso del codice di autorizzazione. Ciò protegge qualsiasi applicazione dalla conoscenza delle credenziali dell'utente che vengono presentate solo al server di autorizzazione. Pertanto, le credenziali di un utente non vengono divulgate. Gli stessi problemi si applicano con l'autenticazione di base, ma nella sezione successiva spiegherò come ROPC sia ancora migliore perché le credenziali dell'utente non devono ancora essere archiviate dal client in ROPC per un accesso persistente da parte dei client.
Si noti che quando l'utente accede al server di autorizzazione, il server di autorizzazione può anche chiedere all'utente di confermare che desidera consentire al client di accedere alle risorse per suo conto o meno. Questo è il motivo per cui viene chiamato server di autorizzazione perché il processo di autorizzazione di un client per accedere alle risorse è implicato nel processo. Se l'utente non autorizza il client, non otterrà l'accesso alle risorse. Allo stesso modo, se l'utente stesso non ha accesso alle risorse, il server di autorizzazione può comunque negare l'accesso e non emettere un token.
Nell'autenticazione di base, anche il server delle autorizzazioni e il server delle risorse sono combinati in un'unica entità. Pertanto, il server delle risorse desidera autorizzare l'utente, quindi richiede le credenziali dal client. Il client fornisce le credenziali utilizzate dal server delle risorse per autenticare l'utente. Ciò significa che più server di risorse richiederanno essenzialmente le credenziali dell'utente.
Emissione di token
I client ottengono token dal server di autorizzazione, li tengono in giro e li usano per accedere alle risorse (maggiori dettagli sui token stessi di seguito). I client non conoscono mai la password dell'utente (in flussi diversi da ROPC) e non devono memorizzarla. In ROPC, anche se i client conoscono la password dell'utente, non devono ancora memorizzarla perché utilizzano questi token per accedere alle risorse. Al contrario, nell'autenticazione di base, se un client non desidera che l'utente fornisca le credenziali in ogni sessione, il client deve archiviare la password dell'utente in modo che possa fornirla la volta successiva. Questo è uno svantaggio principale dell'utilizzo dell'autenticazione di base, a meno che il client non sia solo un'applicazione Web, nel qual caso i cookie possono affrontare alcune di queste preoccupazioni. Con le applicazioni native, di solito non è un'opzione.
C'è un altro aspetto di OAuth2 che consiste nel modo in cui i token vengono emessi e funzionano. Quando un utente fornisce le credenziali al server di autorizzazione (anche in ROPC), il server di autorizzazione può fornire uno o più dei due tipi di token: 1) token di accesso e 2) token di aggiornamento.
I token di accesso vengono inviati al server delle risorse che garantirà l'accesso alle risorse dopo la convalida e di solito hanno una durata breve, ad esempio 1 ora. I token di aggiornamento vengono inviati al server delle autorizzazioni dal client per ottenere un altro token di accesso quando scade e di solito hanno una lunga durata (ad esempio da alcuni giorni a mesi o addirittura anni).
Quando il client fornisce il token di accesso al server delle risorse, guarda il token e dopo la convalida, guarda all'interno del token per determinare se consentire o meno l'accesso. Finché il token di accesso è valido, il client può continuare a utilizzarlo. Supponiamo che l'utente chiuda l'applicazione e la avvii il giorno successivo e il token di accesso sia scaduto. Ora il client effettuerà una chiamata al server di autorizzazione e presenterà il token di aggiornamento supponendo che non sia scaduto. Il server di autorizzazione, poiché ha già emesso il token, lo verifica e può determinare che l'utente non deve fornire nuovamente le credenziali e quindi fornisce un altro token di accesso al client. Il client ora ha di nuovo accesso al server delle risorse. Questo è il modo in cui in genere le applicazioni client per Facebook e Twitter richiedono le credenziali una volta e quindi non richiedono all'utente di fornire nuovamente le credenziali. Queste applicazioni non devono mai conoscere le credenziali degli utenti e possono comunque accedere alle risorse ogni volta che l'utente avvia l'applicazione.
Ora l'utente può accedere al server di autorizzazione (ad es. Nel proprio profilo utente di Facebook), modificare la password senza influire sulle applicazioni client. Continueranno tutti a funzionare correttamente. Se l'utente perde un dispositivo sul quale aveva già un'applicazione con token di aggiornamento, può dire al server di autorizzazione (ad esempio Facebook) di "disconnetterlo" da quelle applicazioni che il server di autorizzazione (ad esempio Facebook) realizzerà non onorando alcuna esistente aggiorna i token e costringe l'utente a fornire nuovamente le credenziali quando tenta di accedere alle risorse attraverso tali applicazioni.
JWT è semplicemente il formato token che viene solitamente utilizzato con OAuth2 e OpenID Connect. I metodi per firmare e convalidare il token sono anche standardizzati con librerie disponibili per quelli invece di ogni server di risorse che implementa l'ennesima soluzione. Pertanto, il vantaggio risiede nella riusabilità del codice che è stato verificato e continua a essere supportato.
Implicazioni sulla sicurezza
L'autenticazione di base sarà più debole quando uno degli scenari di cui sopra è nella foto. Esiste anche un ampio modello di minaccia per OAuth2 disponibile per gli sviluppatori che possono utilizzare i suggerimenti in esso contenuti per evitare vulnerabilità comuni nelle loro implementazioni. Se passi attraverso il modello di minaccia, vedrai che sono coperte anche molte vulnerabilità legate all'implementazione (come open redirector e CSRF). In questa risposta non ho analizzato quelli confrontati con l'autenticazione di base.
L'ultimo grande vantaggio di OAuth2 è che il protocollo è standardizzato e più server di autorizzazione, client e server di risorse lo onorano. Numerose librerie sono disponibili per gli sviluppatori, che vengono mantenute in modo che quando vengono rilevati problemi di sicurezza nelle implementazioni, le librerie vengono aggiornate consentendo l'interoperabilità.
Conclusione
Se stai scrivendo una nuova applicazione, IMO, il caso ideale sarebbe quello di evitare sia l'autenticazione di base che il ROPC a causa dei problemi inerenti. Tuttavia, ogni applicazione ha esigenze, tempistiche, competenza degli sviluppatori ecc. Differenti, quindi la decisione viene presa caso per caso. Ma anche se non avessi più bisogno dell'autenticazione di base, scegliendola, potresti bloccarti in un'architettura che potrebbe non essere facile da estendere (ad esempio se in futuro avessi più server, non vorrai necessariamente avere l'utente fornisce le credenziali a ciascuno di essi piuttosto che fornire al server di autorizzazione una volta sola, che può distribuire token, ecc.)
Nota che non ho risposto al tuo commento su come le credenziali vengono inviate via cavo perché possono essere protette utilizzando TLS o un protocollo simile, o prova del possesso ecc. Come qualcuno ha già suggerito, la codifica base 64 è 0 di sicurezza, per favore non farlo essere illuso da quello. Le differenze sopra menzionate sono di solito a livello architettonico e quindi è lì che mi sono concentrato perché l'architettura è la più difficile da cambiare una volta implementata.
Azure Active Directory B2C Basic , un servizio su cui lavoro ed è stato recentemente rilasciato per l'anteprima pubblica, consente all'applicazione di terze parti di utilizzare AAD come server di autorizzazione con interoperabilità con IDP sociali (come Facebook, Google, ecc.). Inoltre, consente agli utenti di creare i propri account anziché utilizzare gli IDP sociali e questi possono essere successivamente utilizzati a fini di autenticazione. Ci sono anche alcuni altri servizi del genere (ad esempio un altro che conosco è auth0) che possono essere utilizzati dagli sviluppatori per esternalizzare completamente l'autenticazione e la gestione degli utenti per le loro applicazioni e risorse. Le stesse caratteristiche dei protocolli che ho menzionato sopra sono utilizzate dagli sviluppatori per disaccoppiare il server di autorizzazione (AAD), una risorsa (ad esempio le loro API REST), il client (ad esempio le loro applicazioni mobili) e gli utenti. Spero che questa spiegazione sia di aiuto.