Ho letto questo argomento per mesi e sembra che l'intera faccenda possa convergere su ciò che riassumo di seguito. Sto cercando di arrivare al più ideale:
- OAuth2
- OpenID Connect
- SPA / client mobile
- JWT
Soluzione che ha una qualità di sicurezza a livello bancario come il componente di cui sopra. Quindi questo è ciò che sembra avere un senso.
- Utilizza la concessione del codice di autorizzazione senza utilizzare sessioni e cookie lato server poiché questo flusso OAuth è più sicuro rispetto al flusso implicito.
- Non creare sessioni o cookie lato server (Inoltre, forse ricorda di me i cookie per identificare se il client è stato autenticato in precedenza). Questo è meglio per il ridimensionamento e la semplicità generale.
- Restituisce un token di connessione JWT / OpenID al client in modo che il client possa utilizzarlo per fare richieste API e per prendere decisioni di autorizzazione all'interno del client. (Penso che questo sia ciò che è la concessione / il flusso implicito del codice di autorizzazione ibrido OAuth2?). Memorizza il token di connessione JWT / OpenID nella memoria della sessione dei client.
- Hanno token JWT di breve durata e offrono anche token di aggiornamento fino alla disconnessione dell'utente. Il client riceverebbe automaticamente token di aggiornamento a meno che non scadesse / la sessione lato client scada o l'utente si disconnetta.
- Durante il logout (o timeout), rimuovi il token dalla memoria di sessione del browser.
Qualcuno di questo pazzo / suona ragionevole? Salta oltre i token invalidanti, ma sembra ok se i token hanno tempi di vita molto brevi e il client può ottenere token di aggiornamento. Mi piacerebbe implementarlo usando Spring-Boot / Spring Security e Angular 4/5 e mi chiedo se mi sia sfuggito qualcosa di ovvio o forse c'è un approccio ancora più semplice che non sacrifica / riduce la sicurezza?
Pensa anche che questo supererebbe il controllo degli standard di sicurezza di livello "Bancario"?