2015-02-09 19 views
5

Ho aggiornato il generatore jhipster dalla versione 1 alla versione 2. Nella versione precedente abbiamo dovuto scegliere le opzioni di autenticazione quando si generava un nuovo progetto. Abbiamo avuto la scelta tra l'autenticazione dei cookie e l'autenticazione token (con OAuth). Questo è stato molto chiaro per me. Ma nella versione 2.1.1, che abbiamo ora tre scelte:jhipster 2: Qual è la differenza tra l'opzione di autenticazione?

1 > HTTP Session Authentication (stateful, default Spring Security mechanism) 
2 > OAuth2 Authentication (stateless, with an OAuth2 server implementation) 
3 > Token-based authentication (stateless, with a token) 

voglio utilizzare l'autenticazione sia per il web e app mobile (ionico-quadro), che 1-1 tra 2 e 3? Questa scelta rende la mia app scalabile utilizzando i cluster? Grazie

+0

La documentazione ufficiale spiega abbastanza chiaramente la differenza tra diversi tipi di autenticazione http://jhipster.github.io/security.html – Greg

risposta

1

si le informazioni di base sul tipo di autenticazione jhipster qui

http://jhipster.github.io/security/ 

dalla mia esperienza personale in ionico-quadro lavorando con API REST di jhipster, posso dire che non utilizzano l'autenticazione HTTP Session per l'app mobile (framework ionico) perché le app mobili non funzionano insieme ai cookie in generale da cui dipende l'autenticazione delle sessioni HTTP.

Sia OAuth2 e JWT funzionano bene con ionica ibrida app

HTTP sessione di autenticazione

Questo è il meccanismo di autenticazione "classico" Primavera di sicurezza, ma abbiamo migliorato in modo significativo. Utilizza la sessione HTTP, quindi è un meccanismo di stato: se si pianifica di ridimensionare l'applicazione su più server, è necessario disporre di un servizio di bilanciamento del carico con sessioni permanenti in modo che ogni utente rimanga sullo stesso server.

OAuth2 autenticazione

OAuth2 è un meccanismo di sicurezza senza stato, quindi si potrebbe preferire, se si vuole scalare l'applicazione su più macchine. Spring Security fornisce un'implementazione OAuth2, che abbiamo configurato per te.

Il problema più grande con OAuth2 è che è necessario disporre di diverse tabelle di database per memorizzare i token di sicurezza. Se si utilizza un database SQL, forniamo il changlog Liquibase necessario affinché tali tabelle vengano create automaticamente per te.

Poiché Spring Security supporta solo OAuth2 con database SQL, abbiamo implementato anche la nostra versione MongoDB. Generiamo per voi tutte le implementazioni di OAuth2 per MongoDB, così come la configurazione MongoDB necessaria.

Questa soluzione utilizza una chiave segreta, che deve essere configurata nel file application.yml, come proprietà "authentication.oauth.secret".

autenticazione JWT

JSON Web Token (JWT) di autenticazione, come OAuth2, è un meccanismo di sicurezza senza stato, quindi è un'altra buona opzione se si vuole scalare su più server diversi.

Questo meccanismo di autenticazione non esiste per impostazione predefinita con Spring Security, è un'integrazione specifica JHipster del progetto Java JWT. È più facile da usare e implementare rispetto a OAuth2, poiché non richiede un meccanismo di persistenza, quindi funziona su tutte le opzioni SQL e NoSQL.

Questa soluzione utilizza un token sicuro che contiene il nome di accesso dell'utente e le autorizzazioni. Poiché il token è firmato, non può essere modificato da un utente.

La chiave segreta deve essere configurata nel file application.yml, come proprietà jhipster.security.authentication.jwt.secret.

+0

Puoi o qualcuno lo spiega nell'attuale architettura JHipster? Voglio dire, ho visto che il generatore crea lo stesso codice per il gateway, JHipsterRegistry e i microservizi per l'autenticazione (TokenProvider è un esempio), quindi non è molto semplice, gli endpoint della strega dovrebbero avere il meccanismo di autenticazione e il modo in cui scambieranno le informazioni dell'autenticazione – carpinchosaurio

Problemi correlati