Oauth2 vs APIKey in una comunicazione server-server

Chiave API / segreto client ha più senso per la comunicazione servizio-servizio, che sembra essere il tuo scenario da ciò che raccolgo (il tuo back-end al loro servizio API).

Detto questo, OAuth 2 ha un flusso di credenziali delle credenziali del cliente , che può fare una sorta di Chiave API / segreto client / autenticazione basata su certificato: controlla con il tuo provider di terze parti per vedere se lo supportano.

Solitamente OAuth 2 è associato al flusso di concessione del codice di autorizzazione , che è buono quando l'agente utente è un browser poiché è stato progettato per questo, ma non è appropriato per il servizio di assistenza.

Questo è un argomento interessante e ci sono un paio di cose da considerare. Per prima cosa dobbiamo provarci dal provider API, non solo il consumatore.

Chi?

La considerazione principale è Autenticazione vs. "Identità" e Autorizzazioni. Aggiornamento:

• Identità = chi ti dice
• Autenticazione = chi sei veramente
• Autorizzazioni = Cosa puoi fare

Dai un'occhiata a questo post per ulteriori dettagli su ID API e autorizzazioni.

Mentre in questa istanza le autorizzazioni possono essere implicite (dove in virtù dell'autenticazione sei in grado di utilizzare l'API), considera questo: come richiede il provider di un'API per un servizio con il livello di pagamento della sensibilità, voglio sapere che il consumatore è chi dice di essere .

Il passaggio di una chiave API conferma che hai la chiave API: non dimostra che sei autorizzato ad accedere all'API.

Ora, il possesso di un token di accesso OAuth può inizialmente essere visualizzato allo stesso modo, tuttavia gli stati OAuth RFC

The authorization server MUST authenticate the client whenever possible.

OAuth abilita questo fornendo token di aggiornamento, come hai detto, insieme a un URI di reindirizzamento registrato. Suggerisce anche un token minimo per tutte le richieste iniziali e di nuova autenticazione.

Ciò fornisce al provider API molto più controllo, maggiore visibilità e quindi maggiore sicurezza che la loro API non sia stata compromessa.

OAuth funziona anche bene con le autorizzazioni. Se la società gateway di pagamento ha deciso di estendere l'autenticazione per richiedere le autorizzazioni a GET e POST, questo sarebbe meno lavoro e più sicuro rispetto a se si dovesse provare a legare una chiave alle autorizzazioni.

esposizione

Una considerazione secondaria ma pertinente è cosa fare se la chiave API è esposta.

So che voglio essere in grado di fidarmi della chiave, tuttavia potrebbe essere stata violata. Quindi autorizzo anche i client IP IP ... Gli IP possono cambiare, a seconda della configurazione, e possono anche essere falsificati ... Come posso sapere se la chiave viene utilizzata in modo nefasto o no?

Se la chiave API viene poi ri-emessa dopo la violazione, può essere più facile per qualcuno determinare nuove possibili chiavi una volta che la chiave iniziale è nota. Ciò significa che potrebbe essere necessario modificare anche l'algoritmo di gen chiave dei provider.

Se ti è stato rilasciato un token di accesso che, in qualche modo, è stato esposto, una volta che viene aggiornato, l'utente non autorizzato non può essere ri-autorizzato. Posso registrarli per registrare questa richiesta errata e collaborare con il consumatore per diagnosticare la causa principale.

Sommario

La chiave API è stata pensata solo per servire come modulo di ID. In quanto tali, sono sostanzialmente abusati quando implementati come misura di sicurezza primaria.

Se i clienti API devono essere autenticati - come in è necessario verificare il chiamante dell'API e fornire l'accesso a determinate risorse in base a tale verifica - OAuth è la scelta migliore.

Spero che questo aiuti!

NB Per ragioni argomentative, ho assunto che nessuno abbia accesso root ai servizi interni o alla rete, e tutte le comunicazioni over-the-wire sono via HTTPS.

Sì, è vero, potrebbe accadere. Un attacco di replay è abbastanza comune ma ci sono modi per implementarlo in modo sicuro. Il tuo server dovrebbe sicuramente usare il monitoraggio ip, il che significa che una volta che il token è stato rilasciato consentirà solo un IP specifico ma che non risolve il problema dal momento che il compromesso può provenire dall'interno. Il secondo modo è ridurre al minimo i tempi di scadenza che restringono il rischio di esposizione. Infine, c'è sempre WebSocket ... di solito si sincronizza abbastanza velocemente per emettere un nuovo token per richiesta, il che elimina la maggior parte dei rischi, dal momento che per uso aziendale, lo utilizza sul proprio Vlan dedicato che può accedere solo a x port. ... ecc. ecc.

Alla fine della giornata, puoi essere a prova di proiettile tutto ciò che desideri, non puoi ancora sopravvivere a un attacco MITM, specialmente se i certificati di root sono stati compromessi sulla tua macchina.