Utilizzo di OAuth 2.0 senza memoria token

Question

Utilizzo di OAuth 2.0 senza memoria token

#1 da (1 voti)
#2 da (0 voti)

7

Sto costruendo un sistema per un prodotto che richiede autenticazione e autorizzazione. Naturalmente ho scelto di utilizzare OAuth 2.0 in quanto è un protocollo comunemente utilizzato e si è dimostrato utile.

Sto prendendo in considerazione l'implementazione di token senza archiviazione, come descritto qui: link

Questo mi farebbe risparmiare un sacco di problemi con l'archiviazione di token e, naturalmente, significa che devo andare al DB solo per il login iniziale (quando rilascio il token).

Dato che non sto vedendo questo in uso comune - Ci sono degli svantaggi sostanziali per questo approccio? È un grosso compromesso per la sicurezza?

Capisco che non avrò alcune funzionalità (come il logout che cancella il token), ma ritengo che questo avrà grandi vantaggi quando si tratta di ridimensionare l'applicazione.

authentication cryptography oauth

posta AvnerSo 20.10.2014 - 17:41

fonte

2 risposte

Leggi altre domande sui tag authentication cryptography oauth

Password Vault - Enterprise Come supportare la creazione sicura di un account utente su un'API esterna tramite un lavoro in coda?

score 1 · Answer 1

L'uso di token OAuth crittografati è un buon approccio per soddisfare i requisiti di sicurezza nella sezione 10 di RFC-6749 . I token crittografati OAuth sono di uso comune, Facebook è un buon esempio .

I token OAuth scadono in base al parametro expires_in . Il che significa che un determinato token sarebbe valido per un breve periodo dopo che l'utente si è disconnesso, il che è un problema di rischio molto basso che la maggior parte delle applicazioni ignora. Una volta che l'utente si disconnette, gli attacchi di sessione come XSS e CSRF non dovrebbero essere possibili anche se il token OAuth è ancora valido.

score 0 · Answer 2

I token di autenticazione sembrano davvero avere senso per me quando la durata della vita è limitata. Per quanto posso dire, questo schema non altera il fatto che un token intercettato può essere riprodotto quale sembrerebbe essere il problema con tutti gli approcci basati su token semplici? (o forse è solo tardi e non l'ho letto correttamente:)

Certamente, vorrei assicurarmi che ogni client avesse un token indipendente in modo che i rischi fossero limitati ai singoli clienti.

Per contribuire a ridurre l'esposizione dei token, farei in modo che l'app client cancelli il token alla scadenza se possibile & mantieni la vita breve.

I miei esperimenti con l'autenticazione basata su token mi hanno portato a capire che i token dovrebbero essere convalidati contro l'origine del cliente (ad esempio almeno l'indirizzo IP) periodicamente per cercare di prevenire l'intercettazione e l'amp; replay. È possibile mantenere tali informazioni nel token (poiché è crittografato, ovviamente non provarlo con token non crittografati), ma il problema può essere che i token diventano piuttosto grandi, il che può rappresentare un sovraccarico sulle comunicazioni.

Alla fine della giornata, dovrai prendere alcune decisioni in base ai rischi che sei disposto a prendere. Personalmente, per i sistemi ragionevolmente sicuri, penso che preferirei utilizzare un data store NoSQL con basse prestazioni e basse prestazioni per la maggior parte dei casi.