Pensieri sulla mia implementazione JWT

Question

Pensieri sulla mia implementazione JWT

#1 da (1 voti)

4

Quindi ho cercato di imparare il più possibile sulla tokenizzazione JWT e auth0 sembra essere il vero hub di informazioni JWT.

Tuttavia, più leggo sui token di aggiornamento, più mi cruccio: l'idea stessa di un "infinitamente" aggiornabile (o per lo meno una scadenza molto lunga) non si adatta a me.

Quindi ecco cosa ho deciso di implementare.

L'architettura del sistema: 1. API (puro livello API, anche il server di autenticazione al momento): crea i token e li convalida 2. Livello applicazione (richieste di gestione delle boccette).

Quando un utente tenta di accedere all'app, vengono inviati alla pagina di accesso. Inseriscono i loro dettagli e questi vengono inviati all'endpoint / authorize sull'API.

Questi dettagli sono convalidati e un token creato con un reclamo contenente: "iat" rilasciato a "exp" scadenza 30 minuti "oct" ora originale creata

Per quanto riguarda il server di autenticazione e l'API, questo token scadrà tra 30 minuti.

Ora sul livello App, ogni richiesta controlla il token e vede se rimangono meno di 5 minuti prima della scadenza.

Se trova lì, crea il proprio JWT (firmato con lo stesso segreto dell'API). Usa il JWT originale (che sta per scadere) come oggetto payload, quindi lo invia a un endpoint su auth / refresh_token

L'endpoint / refresh_token quindi convalida il token, estrae il token originale dal payload, lo convalida e se è un token valido (non ancora scaduto). Quindi controlla l'ora originale creata e si assicura che non sia stato raggiunto un timeout massimo (impostato dal cliente della nostra App) - questo è un limite rigido del sistema di 12 ore (ma i nostri clienti possono optare per sessioni totali più brevi). Se questi controlli sono OK, crea un NUOVO token e lo rimanda all'App Layer.

In questo modo, il mio pensiero è:

Il server di autenticazione può sempre considerare attendibile questa richiesta di aggiornamento, poiché deve ricevere un JWT attendibile che contenga il JWT originariamente creato dal server di autenticazione. Ciò significa che potrebbe essere stato creato solo dall'App Layer (o da qualsiasi server con il segreto).
Il server di autenticazione non distribuisce infinitamente token di aggiornamento.
Se il segreto è compromesso - sei comunque un proverbiale, e finché non sai che è stato compromesso, non c'è molto che puoi fare - ovviamente abbiamo pedine IP per garantire che le richieste di JWT provengano da fonti attendibili, ma ancora: lo spoofing IP non è difficile se l'hacker sapeva cosa stavano facendo.
L'App Layer, ha la capacità di interrompere l'invio di aggiornamenti uccidendo la sessione utente - quindi un JWT compromesso sarebbe solo "pericoloso" per un massimo di 30 minuti.

Un sacco di persone si preoccupano molto della sicurezza, e giustamente - ma diresti che questo approccio fornisce controlli e saldi adeguati?

In caso contrario, mi piacerebbe sentire idee, miglioramenti nel processo, ecc. La sicurezza non è sicuramente il mio strong seme, quindi tutto l'aiuto sarà molto apprezzato!

Saluti.

authentication authorization jwt web-application

posta Trent 08.04.2016 - 02:13

fonte

1 risposta

Leggi altre domande sui tag authentication authorization jwt web-application

Rileva il traffico wireless (Wifi) con Wireshark Quanto è sicura la password del disco fisso BIOS / UEFI? [duplicare]

score 1 · Answer 1

Alcuni pensieri, non intesi a essere di per sé critici, solo fornendo un feedback:

Nessun motivo per fare in modo che l'app crei i propri JWT. Basta passare il JWT consegnato dal cliente insieme.
Questo potrebbe non essere ciò che si intendeva, ma non è una buona idea avere un inevitabile ritardo nella revoca. In caso di rilevamento di un compromesso intorno a un JWT specifico, è necessario che si verifichi una declinazione immediata, non solo nel JWT reso non rinnovabile.
Non vi è alcun vantaggio nel selezionare alcune finestre arbitrarie entro un periodo di scadenza per eseguire un determinato comportamento di rinnovo, rispetto al solo periodo di scadenza più breve. È confuso e l'ergonomia non è più utile per gli utenti. Le decisioni politiche rilevanti riguardano il fatto che l'attività allunghi automaticamente la sessione (che sarebbe applicata a ogni richiesta, non solo con 5 minuti rimasti), e cosa succede al ricevimento di un token scaduto.
In modo simile, i macchinari per "rinnovare con meno di 5 minuti rimanendo fino a un limite di 12 ore" non differiscono dall'avere un token di aggiornamento che ha una certa durata e viene verificato alla scadenza di un token di autorizzazione. Poi pensa a se le durate della durata di 12 ore sono davvero molto diverse dalla durata della vita di 24 o 48 o qualche altro numero arbitrario.
Pensa all'accesso multi-dispositivo: più refresh + JWT o lo stesso? e accesso simultaneo da un singolo dispositivo. Pensa ad altri potenziali meccanismi per bloccare l'utilizzo di un token, come legare il token a un IP o un user agent specifico.
Pensa se più app saranno coinvolte in questo sistema.

Spero che sia utile.