Qualche suggerimento per programmare un webservice "in abbonamento"

3

Ho programmato alcuni siti web, so che fondamentalmente lo faccio con Python e PHP. Normalmente sono semplici siti Web, ma ora desidero fornire servizi web REST ma solo per utenti autorizzati (consentiti da me).

Ho visto che molti servizi utilizzano i concetti "KEY" e "SECRET_KEY", che sembrano essere ciò di cui ho bisogno (se ho capito bene).

Le mie supposizioni sono:

  1. Se faccio solo un servizio GET per recuperare, ad esempio, tutti i miei clienti, senza più nessuno può recuperare i miei client senza limitazioni.
  2. Avrò bisogno di un generatore KEY per fornire le chiavi per i miei utenti autorizzati, in modo che possano usare i miei servizi web.
  3. Solo con una CHIAVE non è sufficiente: qualcuno può rubare una CHIAVE e soppiantare il mio utente (e questo è il motivo perché esiste una SECRET_KEY, giusto?).

Se tutto questo è giusto, come posso creare / utilizzare un sistema come quello nei miei servizi web? Qualche esempio di open source?

O forse ci sono altre soluzioni facili che non sto considerando?

Il mio obiettivo è consentire ad alcuni utenti di utilizzare i miei servizi web.

    
posta Eagle 18.10.2013 - 15:45
fonte

1 risposta

1

La soluzione è relativamente semplice, una volta che l'hai capito. La spiegazione di base è questa:

Hai un client e un server. Il client ha una chiave privata (o chiave segreta). Il server può recuperare la chiave privata da un database basato sulla chiave pubblica del client. Se il client ora invia una richiesta al server, calcola un hash HMAC da tutti i parametri che invierà comunque oltre ad alcuni extra extra. Questi extra extra sono la chiave privata, un valore di timestamp e nonce.

Il server riceve la richiesta con l'hash e ricalcola l'hash HMAC per verificare che il client reale abbia inviato la richiesta. Poiché la chiave privata può essere ricevuta dal database, nessun dato vulnerabile viene trasmesso via Internet.

Il timestamp e il nonce prevengono attacchi man-in-the-middle che cercano di riprodurre il messaggio. Un tale aggressore avrebbe bisogno di includere il vero valore nonce e timestamp o uno modificato. Con quello modificato, l'hash HMAC non si adatta e con quello originale, il server può riconoscere che una richiesta con gli stessi valori è già stata pronunciata.

In breve, questa è la spiegazione della procedura. È paragonabile a OAuth a due vie.

    
risposta data 14.01.2014 - 20:59
fonte

Leggi altre domande sui tag