Ho bisogno di OAuth per passare una chiave API di un servizio (ora viene passata tramite copia-incolla)?

4

Ho un'applicazione web, diciamo http://web.app/ . È locale per ogni dato utente e accessibile senza autorizzazione. Utilizza un'API di un servizio https://service.app/ . L'utente può accedere ad esso e vedere la sua chiave API. L'utente lo copia e incolla dal servizio all'app e c'è intenzione di renderlo un po 'più semplice.

La prima idea è usare OAuth, ma è leggermente complicato. Devo solo passare una chiave e non ho bisogno di essere sicuro che sia corretto . Se un utente passa una chiave sbagliata, i servizi semplicemente non funzioneranno.

La seconda idea è passarla via richiesta post. Web.app ha un collegamento a https://service.app/getapikey/ con un pulsante 'Passa la chiave', rende la richiesta post a http://web.app/saveapikey/ , quindi l'app web ottiene la chiave.

È una buona pratica non usare OAuth per tale scopo? C'è qualcosa di meglio?

    
posta shukshin.ivan 24.01.2017 - 16:57
fonte

2 risposte

2

Devi considerare diversi fattori qui. Spero che la tua chiave API abbia una scadenza? Anche se lo fa, è vulnerabile a un attacco di riproduzione se un avversario entra in possesso della tua richiesta HTTPS. Come rimedio, puoi introdurre un timestamp o un contatore alla tua richiesta.

Attacchi replica contro il contrappasso

Un timestamp può essere aggiunto al messaggio e crittografato insieme al resto del contenuto del messaggio. Il servizio può recuperare il timestamp dopo la decrittografia del messaggio e fallire la richiesta se il timestamp è troppo vecchio per la soglia questo è già stato concordato. Ciò riduce la finestra di opportunità per riprodurre una richiesta. Il lato negativo di questo approccio è che sia il server che il client devono essere sincronizzati con il tempo.

Un'alternativa a un timestamp è un contatore. Con un contatore, non è necessario essere preoccupati per l'inclinazione tra gli orologi. Tuttavia, i clienti devono implementare a contatore per garantire che il conteggio inviato in una richiesta sia maggiore del conteggio nella richiesta precedente almeno di uno e il numero il server deve conservare una registrazione dell'ultimo contatore ricevuto. Naturalmente, il messaggio deve essere firmato in modo che un utente malintenzionato non incrementa il contatore e riproduce il resto della richiesta.

Codice di autenticazione dei messaggi basato su hash per contrastare l'attacco MITM

Il meccanismo principale per garantire l'integrità dei dati dei messaggi è un codice di autenticazione dei messaggi basato su hash (HMAC). HMAC è solo un pezzo di dati creati tramite un algoritmo di hashing crittografico e una chiave segreta condivisa. Tuttavia, se il messaggio deve essere crittografato per riservatezza, è possibile aggiungere facilmente tale funzionalità utilizzando la stessa chiave privata che utilizziamo per HMAC o puoi introdurre una nuova chiave specifica per la crittografia. Quando un utente invia una richiesta, devi preoccuparti di seguire tre parametri importanti.

  1. La chiave pubblica, che è la chiave associata all'utente
  2. Il contatore
  3. Il Timestamp

Oltre ai parametri, la richiesta include una firma che garantisce che nessuno dei parametri sia manomesso È possibile creare la firma basata non solo sui tre parametri ma anche sull'intero corpo della richiesta se l'obiettivo è quello di assicurarsi che nulla nella richiesta venga modificato. Per assicurarsi che nessuno manchi i parametri, possiamo includere un HMAC-SHA256 di tutti e tre i valori più il richiesta metodo URI e HTTP.

Puoi inserire i seguenti 4 attributi nella tua intestazione.

X-KEY

Questa è la tua chiave API

X-Firma

Se il valore inviato dall'applicazione client in X-Signature corrisponde a HMAC-SHA256 del file i valori di X-KEY, X-Counter, X-Stamp, URI di richiesta e il metodo HTTP, possiamo tranquillamente concludere che nulla è stato alterato durante il trasporto.

X-Stamp

Vengono confrontati il valore inviato dal client e l'ora UNIX dell'ora corrente. Se la l'inclinazione tra questi due è entro il limite di tolleranza consentito, la richiesta non è un replay. Il tempo UNIX è il numero di secondi trascorsi dalla mezzanotte del 1 gennaio 1970 Coordinato Universal Time (UTC).

X-Counter

Se il valore inviato dal client è maggiore dell'ultimo contatore ricevuto nel record tenuto da il server, la richiesta non è un replay. Anche se io uso sia il timestamp che il contatore in esempio di implementazione in questo capitolo, uno in genere è abbastanza buono, a seconda del tuo esigenze. Se i tempi di clock sono ragionevolmente sincronizzati, un timestamp è l'approccio migliore perché non c'è sovraccarico in termini di memorizzazione del contatore nel lato dell'API Web o incremento nel lato client.

conclusione

È meglio utilizzare già framework collaudati come OAuth per soddisfare le tue necessità. Ma se pensi che sia troppo complesso, devi considerare le cose che vengono spiegate in questa risposta.

    
risposta data 27.01.2017 - 00:49
fonte
0

Puoi crittografare la chiave, quindi usare base64_encode su di essa e pubblicarla. Oppure puoi inviarlo tramite curl.

La chiave può essere crittografata o decifrata attraverso più di un modo ed è sempre più facile consegnare una chiave / passata crittografata con la codifica di base 64 per salvarla o trasportarla.

Se si tratta di una rete locale ed è necessario utilizzarla da una stazione all'altra, arricciare è una buona idea rendendo tali stazioni IP statici (LOCAL).

Altrimenti se lo usi su una macchina, usa la sessione php per trasferire la chiave

    
risposta data 27.01.2017 - 00:15
fonte

Leggi altre domande sui tag