Come proteggere i servizi Web RESTful?

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

Opzioni:

TLS (HTTPS) +

• HTTP di base (pc1oad1etter)
• HTTP Digest
• OAuth a due gambe
• un approccio basato sui cookie
• certificati client (Tom Ritter e qui )
• Richieste firmate utilizzando HMAC e una durata limitata

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

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

Proteggi la tua API REST ... nel modo giusto

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

Carichi la chiave pubblica dei certificati client del certificato (e i certificati del loro firmatario, se necessario) nel tuo server web e il server web non accetterà connessioni da nessuno tranne le persone che hanno le chiavi private corrispondenti per i certificati conosce. Funziona sul livello HTTPS, quindi potresti persino essere in grado di saltare completamente l'autenticazione a livello di applicazione come OAuth (a seconda dei tuoi requisiti). Puoi astrarre un livello e creare un'autorità di certificazione locale e firmare le richieste di certificati dai client, consentendoti di saltare i passaggi "falli entrare in ufficio" e "carica i certificati sul server".

Dolore al collo? Assolutamente. Va bene a tutto? No. Molto sicuro? Sì.

Tuttavia, si basa sul fatto che i clienti mantengano i propri certificati al sicuro (non possono pubblicare le loro chiavi private online) e di solito viene utilizzato quando si vende un servizio ai clienti piuttosto che consentire a chiunque di registrarsi e connettersi.

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

HTTP Basic + HTTPS è un metodo comune.

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

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

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

Sebbene sia vero che se qualcuno intercetta il tuo token portatore può impersonarti quando chiama l'API, ci sono molti modi per mitigare tale rischio. Se dai ai tuoi token un lungo periodo di scadenza e ti aspetti che i tuoi clienti li memorizzino localmente, hai un rischio maggiore che i token vengano intercettati e utilizzati in modo improprio rispetto a se dai ai tuoi token una scadenza breve, richiedi ai clienti di acquisire nuovi token per ogni sessione, e consiglia ai clienti di non rendere persistenti i token.

Se è necessario proteggere i payload che passano attraverso più partecipanti, è necessario qualcosa di più di HTTPS / SSL, poiché HTTPS / SSL crittografa solo un collegamento del grafico. Non è colpa di OAuth.

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