JWT o chiavi pubbliche-private per il servizio di servizio delle chiamate API

4

Sto cercando di configurare l'autenticazione tra due servizi applicativi. Il servizio A chiamerà il servizio B e desidero che il servizio B accetti solo le chiamate (http) dal servizio A, da nessun'altra parte.

So come funziona l'autenticazione JWT e potrei implementarla. Se capisco correttamente (penso di sì, ma correggimi se sbaglio), funziona così:

  • il servizio A richiede una JWT dal servizio B (o un server di identità, ma assumiamo point-to-point)
  • il servizio B risponde con il JWT, firmato con il segreto del servizio B
  • Il servizio
  • effettua la chiamata al servizio B e include il JWT
  • il servizio B ispeziona il JWT e può sapere se è stato effettivamente il servizio A a effettuare la chiamata, senza alterare il JWT

Ma la prima chiamata è effettivamente necessaria? Non potrei fare questo:

  • servizio A firma ogni richiesta con la chiave privata del servizio A
  • Il servizio
  • B decrittografa la richiesta con la chiave pubblica del servizio A
  • Il servizio
  • B ora sa se la richiesta è in realtà dal servizio A

Lavorerò su https e non avrò bisogno di reclami. Tutto quello che devo sapere è se la richiesta è originata dal servizio A. Perché solo il servizio A è autorizzato a chiamare il servizio B, ma quando lo fa, ha accesso a tutti gli endpoint API (quindi non sono necessarie dichiarazioni).

Sembra più semplice utilizzare la crittografia asimmetrica al posto di JWT, ma mi chiedo se sia altrettanto sicuro, corretto e standard.

    
posta Peter 09.03.2018 - 09:03
fonte

2 risposte

4

Il JWT è stato creato per gestire una vasta gamma di situazioni (reclami differenziati, server di identità separato, molti utenti, ecc.). La tua situazione è abbastanza semplice: hai solo un client (A) che deve comunicare con un server (B).

Potresti gestire questo caso con JWT se lo desideri, ma non è necessario. Sarebbe davvero eccessivo, dal momento che il JWT richiede una qualche forma di autenticazione nel primo passo. E se devi sistemarlo, perché non usarlo fino in fondo? L'impostazione di chiave privata-privata che suggerisci funzionerebbe altrettanto bene. Quindi, a meno che non ti aspetti che i tuoi requisiti cambino, andrei con quello che è più semplice da implementare.

Qualcosa di molto simile al tuo suggerimento è in realtà già implementato in TLS, ovvero l'autenticazione del client. In tale configurazione, il client deve fornire un certificato al server per l'autenticazione. Potresti volerlo esaminare.

    
risposta data 09.03.2018 - 09:37
fonte
2

In un certo senso lo si punta, usando i token di accesso JWT in un'infrastruttura Oauth, con un server di autorizzazione appropriato (AS) è il modo standard per farlo. Offre metodi standard per ottimizzare l'accesso in un secondo momento, tramite un servizio centrale. E si adatta bene.

La tua soluzione è probabilmente sicura su piccola scala, se non hai bisogno di dare accesso a molti utenti o altri servizi. Devi occuparti della gestione delle chiavi, che potrebbe essere una chiave simmetrica in modo sicuro.

Questo renderebbe qualcosa come il protocollo webhook di Github: link

Questo utilizza un'intestazione HMAC sulla richiesta.

    
risposta data 09.03.2018 - 09:39
fonte

Leggi altre domande sui tag