Autorizzazione remota per ogni richiesta di risorsa REST

0

Abbiamo un'architettura di microservizi. Uno dei componenti è un'autenticazione & Servizio di autorizzazione, che implementa lo standard OAuth2 utilizzando JWT crittografati. Su ogni autenticazione di un utente a qualsiasi componente, il componente invia un REST al servizio per ottenere un token di accesso. In ogni interazione REST di un utente con qualsiasi componente, il componente invia un REST con il token di accesso dell'utente al servizio per autorizzarne il diritto a effettuare l'interazione. Ho due dubbi:

  1. I componenti parlano su SSL. OAuth2 richiede che i JWT siano crittografati, quindi li seguiamo ciecamente e li crittografiamo. Quindi, il token crittografato viaggia all'interno dell'SSL che non ha senso per me, ma abbiamo l'obbligo di seguire OAuth2. Ritengo che OAuth2 significhi che i JWT devono essere crittografati in generale, indipendentemente dal fatto che utilizziamo o meno il protocollo crittografato (ma non ne sono sicuro).
  2. Chiediamo sempre un servizio remoto per la verifica dei diritti, ma ritengo che un componente potrebbe semplicemente utilizzare una chiave pubblica per verificare la firma del JWT e leggere semplicemente il carico utile per trovare la voce ROLE richiesta in là senza coinvolgere la rete .
posta Sam 21.08.2017 - 13:04
fonte

1 risposta

1
  1. Per citare RFC 6750 (il framework di autorizzazione OAuth 2.0: utilizzo token bearer) qui:

In some deployments, including those utilizing load balancers, the TLS connection to the resource server terminates prior to the actual server that provides the resource. This could leave the token unprotected between the front-end server where the TLS connection terminates and the back-end server that provides the resource. In such deployments, sufficient measures MUST be employed to ensure confidentiality of the token between the front-end and back-end servers; encryption of the token is one such possible measure.

  1. In teoria è possibile ma questo significa che se qualcuno riesce a trovare un exploit nella generazione di token, una collisione della firma che il JWT ha, che dà diritti maggiori o qualcosa di simile, avrà più accesso al sistema. Trasmettendo questo a un servizio che non è modificabile dall'esterno, si riduce il rischio che ciò accada. Ovviamente ciò significa che devi proteggere correttamente il servizio di verifica dei diritti poiché, se ciò è compromesso, sei incasinato in entrambi i modi.

Per continuare sul punto # 1, ci sono ulteriori informazioni all'interno di sezione 5.2 che potrebbero essere particolarmente interessanti per te considerando la prima domanda. Ho scoperto personalmente che la maggior parte delle RFC sono molto brave nel dichiarare il ragionamento dietro le decisioni e le raccomandazioni, quindi leggerle è di solito molto utile anche se all'inizio potrebbero sembrare documenti noiosi.

    
risposta data 21.08.2017 - 13:47
fonte

Leggi altre domande sui tag