DOMANDA Autenticare pagine chiamanti dello stesso dominio

Pubblicità
G

Giulio95

Nuovo Utente
Messaggi
36
Reazioni
4
Punteggio
26
Salve,

grazie a chiunque si interessi alla mia domanda.

Sto realizzando una piccola Web Application in Node.js (express) e mi e' sorto un dubbio.

Ho delle rotte che restituiscono diverse sezioni (pagina html con i javascript annessi).
E sullo stesso dominio diverse API.

Se volessi fare in modo che alcune API possano essere chiamate solo da determinate sezioni come potrei fare ?

Praticamente l'utente si logga ed ha accesso a 2 sezioni.
Ma vorrei evitare che manualmente da console, mentre si naviga in una sezione, si possano chiamare le API dedicate all'altra.

Non so, magari non e' una misura necessaria, dopotutto perche' un utente gia' autenticato dovrebbe mettersi a fare chiamate manuali da console, probabilmente andando contro i suoi interessi.
Considerando anche che sono in grado di nascondere/mostrare le varie sezioni in funzione di chi si e' autenticato.

Comunque pensavo di generare un JWT da associare alla pagina html di root della sezione. Ma non so se ha senso dato che il JWT credo che si possa ricopiare e riallocare all'altra pagina, a meno che il path al quale viene associato non sia verificabile in qualche modo.

Se qualcuno sa approfondire l'idea o esporre altre soluzioni, sarei grato per l'eventuale illuminazione.

Grazie mille e saluti.
 
Ultima modifica:
allora le API dovrebbero essere protette con un jwt token, e bearer token in maniera tale che senza quel token non possano essere chiamate, altrimenti chiunque abbia la tua rotta della api può effettuare una get/post/put.

Dopo di che una volta che hai fatto questo non avrai alcun problema a fare le chiamate, e in tal caso in una pagina effettuare solo le chiamate che ti servono

e ti basta dare alle api un path differente tipo: /api/v1/nomepath/nomeapi cosi da rispettare anche il pattern restfull api
 
Ok grazie della risposta,

per approfondire do ulteriori dettagli.

Per questa App, l'utente fa una autenticazione sull'active Directory di Microsoft.
Al client viene dato un cookie (Same site = none, secure = true) e i dati di sessione sono memorizzati lato server con express session.
Questo perche' l'AD microsoft restituisce i tokenId con i dati dell'utente, e per il refresh della sessione, tutti dati sensibili a mio avviso da non salvare in un jwt lato client.

Sul database interno vengono salvate le informazioni salienti degli account microsoft autorizzati, ALL'INTERNO DI UN APPOSITO FILE DI CONFIGURAZIONE DEDICATO AL SINGOLO UTENTE, come l'ID dell'account, il tenant di appartenenza ecc. che dovranno corrispondere a quelle restituite nel token di Microsoft.

Quando l'utente fa una richiesta di rete, in pratica le api controllano prima:

Se l'utente ha una sessione express attiva grazie all'esito positivo della login Microsoft,
poi se all'interno della sessione express e' presente un tokenId Microsoft e se e' ancora valido.
Se il tokenId Microsoft non e' piu' valido, ne tenta il refresh silente, altrimenti l'utente deve rifare la login manualmente.

Dopodiche' controllano se nel File di configurazione dell'utente, estratto grazie alle info del token Microsoft presente in sessione, e' presente il nome delle API utilizzabili da lui, affinche' possano funzionare tutte le sezioni, a lui sempre associate nel file di configurazione.

Io lascerei cosi sinceramente, ma non so se e' un problema che l'utente possa chiamare le api di tutte le sezioni ad esso associate manualmente.
Magari anche un consiglio su come testare la sicurezza dell'app non sarebbe male.

Non mandatemi a quel paese please, grazie.
 
per me aveva senso, spostare gli utenti di AD su AZURE ACTIVE DIRECTORY e passare direttamente sulla login di MS, cosi da poi fare un redirect dopo autenticazione. Cosi ti stai solo complicando la vita.
AD ed AZURE AD si possono syncronizzare facilmente

Salvare info nei cookie, cosi se ti clonano la browser session, hanno tutti i tuoi dati e ti possono emulare, è cosi che fregano gli accssi anche di steam.

Queste cose devono essere gestite server side, non cosi
 
Ciao.

Perdonami, con active Directory di Microsoft intendo AZURE ACTIVE DIRECTORY, gli utenti vengono reindirizzati sulla pagina di login microsoft e poi ritornano col redirect.

Semplicemente Esiste anche questo file di configurazione per gestire i servizi e le sezioni accessibili a quell'utente Microsoft specifico. Sempre che io lo abbia censito nel tenant.
 
si ok ma che ti frega di avere indietro il token di ad? cosa te ne fai? se è autenticato vuol dire che nel tenant esiste, dovresti avere un tuo database dove gestisci le user permission degli utenti x dirgli a cosa sono abilitati e a cosa no
 
Ok, capisco il tuo dubbio,

nel Token di AD sono presenti le informazioni di riconoscimento dell'utente, il nome ad esempio, quindi nel database interno dell'applicazione censisco le permission e le associo a quel nome (per semplificare).

Quindi quel token Id mi serve perche' lo memorizzo in sessione quando l'utente si logga, e ad ogni richiesta di rete posso verificare il nome dell'utente dalla sessione e recuperare le sue permission.
 
Per le api ti basterebbe proteggerle con il jwt token e verificare che tipo di auth ha su quella api. Così ad esempio se ti grabbano un token valido ma non hanno la permission per chiamare quella api non potranno effettuare nessuna chiamata
 
Pubblicità
Pubblicità
Indietro
Top