Attualmente stiamo progettando un'API REST e stiamo pensando di metterlo al sicuro.
Passando attraverso molta documentazione, è diventato chiaro che sono disponibili 2 opzioni.
Autenticazione HMAC
Mediante hashing con HMAC-sha1 una serie di elementi predefiniti con secret_key, firmiamo la richiesta. La verifica viene eseguita facendo esattamente lo stesso lato del server di elaborazione e confrontando gli hash risultanti.
La nostra implementazione va così:
- Ottenere la data / ora corrente
- Creazione di HMAC:
hmac(full_url + request_body + timestamp + secret_key + token) - Invio della firma come:
clientId + hmac_signature + timestamp + token
Il vantaggio principale di questo è che il tasto segreto non viene mai trasmesso nella richiesta, il che impedisce principalmente gli attacchi di riproduzione. Ma come svantaggio dobbiamo memorizzare le credenziali del cliente (tasto segreto) in un formato raw nel nostro database. E se il nostro database viene compromesso, potremmo anche revocare tutte le credenziali dei client API correnti.
Autenticazione HTTPS
L'utilizzo di SSL tramite la nostra API ci consentirà di creare un canale sicuro per lo scambio di informazioni private.
Fondamentalmente inviamo le stesse informazioni senza doverle modificare con HMAC.
Il nostro design sarà esattamente come (o molto simile a) la specifica OAuth2.
Il confronto con HMAC ha molti vantaggi in quanto deleghiamo la maggior parte del lavoro a SSL. E i client non devono includere una libreria per hashing come con HMAC. Infine, il nostro database è sicuro poiché la chiave segreta del client sarà memorizzata in modo sicuro.
Ma se qualcuno annota con successo una richiesta, può rubare la chiave segreta e iniziare a creare le sue richieste.
C'è un modo per utilizzare i vantaggi di HTTPS senza inviare credenziali chiare e senza dover memorizzare credenziali chiare?
Uno dei nostri progetti alternativi utilizzava lato client privato / pubblico generato dalla chiave e lo utilizzava per scambiare una chiave per crittografare secret_key per future richieste. Ma non molti browser hanno questa capacità ( <keygen> ) ed è piuttosto una seccatura per le applicazioni mobili.