OAuth2 overkill per le piccole imprese

Il problema con l'autenticazione di base su SSL dipende dal passaggio delle credenziali dell'utente con codifica inversa con ogni richiesta API. Si tratta di un problema di sicurezza perché, a meno che non si intenda consentire all'utente di inviare le proprie credenziali ad ogni richiesta, è necessario memorizzare le credenziali dell'utente in qualche modo sul dispositivo client o nel browser (i browser di solito memorizzano le credenziali di autenticazione di base e le memorizzano in un modo difficile da chiarire). Ogni volta che vengono memorizzate le credenziali dell'utente, lascia spazio a qualcun altro per accedervi.

È molto meglio usare una specie di token che è concesso al login, ha una data di scadenza e può essere revocato in qualsiasi momento. I token sono più sicuri da usare perché anche se qualcuno accede al token, hanno accesso al tuo sistema e non tutti i sistemi con cui la tua password usa la stessa password.

OAuth2 potrebbe essere eccessivo per le tue app, ma potrebbe essere una buona scelta perché ti costringe a utilizzare alcune buone pratiche di sicurezza e molte persone lo usano da un po ', quindi è piuttosto maturo come protocollo di sicurezza. Ogni protocollo che creerai probabilmente contiene buchi di sicurezza a cui non hai mai pensato. È meglio prevenire che curare.

Hai ragione, OAuth2 è eccessivo in questo caso specifico e nonostante i commenti, aggiungerà complessità non necessaria all'intero progetto. Detto questo, ricorda che OAuth2 non è un protocollo di autenticazione, quindi un motivo in più per lasciarlo da parte per ora. Ad ogni modo, dai un'occhiata a questo articolo e ottieni le tue conclusioni e decidi se è adatto a te .

L'obiettivo principale di OAuth2 è l'autorizzazione di diversi fornitori di applicazioni per condividere i dati senza la necessità di condividere le credenziali. Presumo che non sia il tuo caso (ancora).

Ad esempio:

I autorizzo Instagram per pubblicare le mie foto sulla bacheca di Facebook. E io autorizzo Facebook a condividere i miei dati e i miei contatti con Instagram .

Questo è tutto. Tuttavia, molti sviluppi là fuori implementano OAuth2 come server di sicurezza dedicati (autorizzazione e autenticazione). Non è né giusto né sbagliato. È solo la soluzione più adatta alle loro esigenze.

Non dovresti mai implementare qualcosa solo perché tutti gli altri lo fanno ¹ . Se lo fai, è probabile che finirai con una soluzione inadatta. Nella sicurezza una delle preoccupazioni più importanti è l'idoneità. Le precauzioni di sicurezza non idonee possono causare falle di sicurezza impreviste.

I problemi con le autenticazioni di base ( tra altri ) sono due:

• Codifica debole (base 64) e formato prevedibile delle credenziali crittografate.

• Persistenza nel lato client.

I browser memorizzano le intestazioni di autenticazione di base al fine di non chiederti le credenziali più e più volte. Ciò non accade con le chiamate asincrone (Ajax), di conseguenza, dobbiamo memorizzare le credenziali da qualche parte sul lato client. Questo ci porta al LocalStorage e ai cookie, entrambi sensibili agli attacchi XSS .

Questa vulnerabilità sarà presente indipendentemente da ciò che archiviamo, tuttavia, se dovessimo scegliere, dovremmo scegliere di esporre un token ben criptato, e questo non è il caso dell'autenticazione di base.

Sebbene il primo (token crittografati) possa rendere vulnerabile il mio account, la seconda (64 credenziali codificate di base) sta dando via le chiavi della casa.

Quindi cosa? Poiché devi ancora implementare un processo di accesso e hai ancora bisogno di un solido meccanismo basato su token per l'autenticazione e l'autorizzazione, JWT è probabilmente la scelta migliore.

È semplice, è ben documentato ed è ampiamente supportato dalla comunità. E nel complesso, è adatto.

A questo punto potresti essere interessato a Scheda Cheat di sicurezza OWASP REST . La sicurezza è tutta una questione di consapevolezza e precauzioni adeguate. ²

Nota: OAuth2 e JWT non si escludono a vicenda. Possiamo combinare entrambi. Infine, le minacce alla sicurezza sono diverse per le applicazioni Web e per le applicazioni mobili e quindi le rispettive misure di sicurezza. Ecco perché l'idoneità è importante.

^{1: Questo non significa che devi reinventare la ruota. Diavolo, no! Usa OAuth2 quando hai bisogno di OAuth2. È così 2: Che tu implementi OAuth2 o JWT, SSL è un must}

Non penso che sia eccessivo. Ci sono tonnellate e tonnellate di librerie per client e server. Questo è un protocollo standard utilizzato praticamente da tutto oggi. Ignorare questo standard perché pensi che sia eccessivo è sciocco. Invece dovresti passare un po 'di tempo a capire di cosa si tratta e l'ampiezza dello standard. Sono sicuro che sarà in grado di soddisfare il tuo caso d'uso.