ID utente esterno a ID utente interno

Question

ID utente esterno a ID utente interno

#1 da (0 voti)
#2 da (0 voti)

-1

Esiste un'API interna, il client REST su DB, tutti i metodi richiedono l'ID utente come parametro. L'ID utente è un valore intero - PK numerico nella tabella utente.

C'è anche un'API pubblica, che è come un gateway Pro + Auth +: controlla il token JWT, estrae l'ID utente e quindi reindirizza all'API interna. Quindi ora l'ID utente viene passato come parte del token JWT, quindi tutti possono estrarre / conoscere il valore - il problema che voglio risolvere.

La sete di ciò che pensavo fosse di cambiare l'API pubblica per lavorare con un ID utente esterno (GUID per esempio): - aggiungere una tabella di mappatura aggiuntiva per avere una mappatura tra ID esterno e interno; - L'API esterna prende l'ID esterno da JWT, fa in modo che la query recuperi l'ID utente interno corrispondente - chiama l'API interna utilizzando l'ID utente interno

Ciò che non mi piace in questo approccio è una query aggiuntiva a DB con ogni richiesta. L'uso della memorizzazione nella cache può ridurre il numero di query, ma ...

Un'altra opzione, a quanto vedo, è usare il token JWE al posto di JWT. Almeno uno svantaggio di questo approccio è rappresentato dalle spese di crittografia / decrittografia.

api security microservices

posta Set 09.07.2016 - 00:35

fonte

2 risposte

Leggi altre domande sui tag api security microservices

In che modo, in Eclipse, lavoro con un progetto Maven esistente in GitHub senza dover controllare il mio file .project? Dove si inserisce Firebase?

score 0 · Answer 1

So right now User ID is passed as part of JWT token, so everyone can extract/know it value - the problem that I want to solve.

Il JWT dovrebbe essere accessibile solo dall'utente proprietario. Pertanto, se si utilizza HTTPS, solo il server e il client conoscono il valore JWT. Quindi, non sono sicuro che ci sia un problema qui.

Ad ogni modo, le prime opzioni mi sembrano migliori (è il solito modo di farlo quando usi Oauth2 con terze parti).

Inoltre, potresti creare una "API intermedia" che rimuove il JWT e reindirizza le richieste, ma non sono sicuro che questo approccio abbia senso per la tua architettura.

score 0 · Answer 2

Quando si usano le parole "interno" e "esterno" è spesso utile aggiungere la frase "... rispetto a [X]". Non sono chiaro se il tuo identificativo proposto sia esterno rispetto al codice web o se sia esterno rispetto al database (il che significa che il web layer funziona anche con l'ID esterno).

Dato il poco che so della tua situazione, ti suggerirei di avere bisogno di un identificatore esterno rispetto al database . Il JWT e tutte le chiamate API devono utilizzare questo identificatore esterno. Inoltre, tutto il codice API che accede al database dovrebbe utilizzare anche l'ID esterno.

L'ID interno, una chiave primaria intera / crescente, è un dettaglio di implementazione che è significativo solo per il database. Nella maggior parte dei casi non vorrai esporlo a qualcosa di diverso dal database stesso. È possibile, ad esempio, che un giorno si vorrà passare a un database distribuito partizionato e si vorrà che tale identificatore sia un GUID invece di un intero in modo da poter disporre di inserti distribuiti. Se il numero intero è esposto al codice API, dovrai riscrivere gran parte del codice web. Ma se la si mantiene interna al database, sarà sufficiente regolare una piccola quantità di codice SQL e nessuno dei parametri della stored procedure dovrà essere modificato, potrebbero continuare a utilizzare lo stesso vecchio ID esterno di prima.

Con questo approccio eviti ulteriori chiamate al DB; il codice web non ha mai bisogno di conoscere l'ID interno, quindi non è necessario alcuna chiamata per recuperarlo. Il livello SQL necessiterà di un join aggiuntivo, ma se si tratta solo di mappare un ID esterno a una chiave interna, tutto ciò di cui avrà bisogno è un singolo indice di ricerca su un indice di copertura, che avrà un impatto sulle prestazioni molto basso, molto inferiore a una rete andata e ritorno.