web-services api - Come proteggere i servizi web RESTful?




cosa sono (4)

Se scegli tra le versioni di OAuth, vai con OAuth 2.0.

I token bearer OAuth devono essere utilizzati solo con un trasporto sicuro.

I token bearer OAuth sono sicuri o insicuri solo quanto il trasporto che crittografa la conversazione. HTTPS si occupa della protezione dagli attacchi di replay, quindi non è necessario che il token al portatore protegga anche dal replay.

Se è vero che se qualcuno intercetta il tuo token bearer che può impersonare te quando chiami l'API, ci sono molti modi per mitigare tale rischio. Se dai tuoi token hai un lungo periodo di scadenza e ti aspetti che i tuoi clienti memorizzino i token a livello locale, hai un rischio maggiore che i token vengano intercettati e utilizzati in modo improprio rispetto a quelli che danno ai token una breve scadenza, richiedono ai clienti di acquisire nuovi token per ogni sessione, e consigliare ai clienti di non persistere i token.

Se è necessario proteggere i payload che passano attraverso più partecipanti, allora è necessario qualcosa di più di HTTPS / SSL, poiché HTTPS / SSL crittografa solo un link del grafico. Questo non è un difetto di OAuth.

I token al portatore sono facili da ottenere per i clienti, facili da utilizzare per le chiamate API e sono ampiamente utilizzati (con HTTPS) per proteggere le API pubbliche di Google, Facebook e molti altri servizi.

Devo implementare servizi web RESTful sicuri. Ho già fatto delle ricerche usando Google ma sono bloccato.

Opzioni:

TLS (HTTPS) +

Ci sono più opzioni possibili da considerare? Se OAuth allora quale versione? Ha importanza? Da quanto ho letto finora OAuth 2.0 con token al portatore (cioè senza firme) sembra essere insecure .

Ho trovato un altro articolo molto interessante sull'autenticazione basata su REST .

Proteggi la tua API REST ... Il modo giusto


HTTP Basic + HTTPS è un metodo comune.


C'è un altro metodo molto sicuro. Sono certificati client. Scopri come i server presentano un certificato SSL quando li contatti su https? Bene, i server possono richiedere un certificato da un cliente in modo che sappiano che il cliente è chi dicono di essere. I clienti generano certificati e li consegnano su un canale sicuro (come entrare nel tuo ufficio con una chiave USB, preferibilmente una chiave USB non trojan).

Caricare la chiave pubblica dei certificati del client cert (e dei relativi certificati del firmatario, se necessario) nel server Web e il server Web non accetterà connessioni da nessuno, ad eccezione delle persone che dispongono delle chiavi private corrispondenti per i certificati lo sa. Funziona sul livello HTTPS, quindi potresti addirittura saltare l'autenticazione a livello di applicazione come OAuth (a seconda delle tue esigenze). È possibile astrarre un livello e creare un'autorità di certificazione locale e firmare le richieste di certificazione dai client, consentendo di saltare i passaggi "falli entrare in ufficio" e "carica certificati sul server".

Dolore al collo? Assolutamente. Buono per tutto? No. Molto sicuro? Sì.

Fa affidamento sul fatto che i clienti mantengano i loro certificati al sicuro (non possono pubblicare le loro chiavi private online), e di solito è usato quando vendi un servizio ai clienti piuttosto che permettere a chiunque di registrarsi e connettersi.

Ad ogni modo, potrebbe non essere la soluzione che stai cercando (probabilmente non è onesto), ma è un'altra opzione.


In realtà l'ho implementato in PHP usando il client Guzzle per creare una libreria client per l'API, ma il concetto dovrebbe funzionare per altre piattaforme.

Fondamentalmente, emetto due token, uno corto (5 minuti) uno e uno lungo che scade dopo una settimana. La libreria client utilizza il middleware per tentare un aggiornamento del token breve se riceve una risposta 401 ad alcune richieste. Riprenderà quindi la richiesta originale e, se è stata in grado di aggiornare, ottiene la risposta corretta, in modo trasparente all'utente. Se fallisce, invierà semplicemente il 401 all'utente.

Se il token breve è scaduto, ma ancora autentico e il token lungo è valido e autentico, aggiornerà il token breve utilizzando un endpoint speciale sul servizio che il token lungo autentica (questa è l'unica cosa per cui può essere utilizzato). Utilizzerà quindi il token breve per ottenere un nuovo token lungo, estendendolo in tal modo un'altra settimana ogni volta che aggiorna il token breve.

Questo approccio ci consente anche di revocare l'accesso entro al massimo 5 minuti, il che è accettabile per il nostro uso senza dover memorizzare una lista nera di token.

Modifica in ritardo: rileggere questo mese dopo che era fresco nella mia testa, vorrei sottolineare che è possibile revocare l'accesso quando si aggiorna il token breve perché dà l'opportunità di effettuare chiamate più costose (es. Chiamare il database per vedere se l'utente è stato vietato) senza pagare per ogni singola chiamata al tuo servizio.





web-services security rest oauth restful-authentication