Implementazione del singolo punto di autenticazione

8

Sto costruendo una serie di app Web collegate a un singolo punto di autenticazione. In sostanza, un utente tenta di accedere a un sito, se non autenticato vengono reindirizzati alla pagina di accesso del sistema di autenticazione centrale. Una volta effettuato il login, vengono reindirizzati alla loro app. Da quel momento in poi, se accedono a qualsiasi altra app, verrebbero automaticamente autenticati.

Un paio di dettagli aggiuntivi: 1) le app saranno tutte in esecuzione nello stesso dominio, quindi posso usare i cookie di dominio, il che rende le cose più facili; 2) gli utenti possono avere accesso ad alcune app e non ad altre, quindi è necessario tenerne conto; 3) l'utente deve essere in grado di recuperare le autorizzazioni specifiche per ogni app.

Ho implementato qualcosa, ma non ne sono felice al 100%. In questo momento, questo è quello che ho: 1) web app controlla l'esistenza di una sessione (specifica per l'app) e un cookie che è un token JWT che è stato inviato dal sistema di autenticazione centralizzato; 2) se il cookie non esiste, reindirizzamento alla pagina di accesso sul sistema di autenticazione; 3) una volta che l'utente effettua il login, vengono reindirizzati alla loro app passando in un token JWT; 4) l'app verifica il token tramite una chiamata API REST al sistema auth (facendo in modo che le chiamate API REST si basino su un token di accesso separato), se è valido, il token JWT viene salvato come cookie e una sessione viene avviata con il utente loggato; 5) se la sessione dell'app scade, controlla se il cookie esiste e se lo fa l'app fa lo stesso del punto 4, verifica il token e reinizia la sessione; 6) al logout, il sistema elimina solo il cookie, assicurando che l'utente sia disconnesso da tutte le app; 7) se il token scade, l'app utilizza il token scaduto per richiederne uno nuovo, in cui la firma del token e altre attestazioni vengono convalidate prima di emetterne una nuova, l'unica cosa che non viene convalidata è la richiesta di scadenza.

Per chiarire, viene utilizzata l'esistenza di una sessione specifica per l'app in modo da non dover continuare a effettuare chiamate API REST in modo costante per verificare il token. Ma dato che il token è stato verificato una volta, sarebbe sicuro usare semplicemente quel cookie come indicatore della presenza di una sessione valida?

Una cosa di cui non sono sicuro è che il mio token deve avere qualcosa che indichi a quale app è perché possono essere fatte altre chiamate API REST usando il token per ottenere risorse specifiche per le app. Ma se ottengo un token per app1 e quindi accedi ad app2, app2 si baserà sul cookie generato da app2. Sembra quindi vorrei avere due token, uno che può essere memorizzato come cookie di dominio per indicare che l'utente è autenticato e un altro che sarebbe effettivamente specifico per le app e che può essere usato per effettuare chiamate API REST per altre app- risorse specifiche.

Sono troppo complicato, o la mia linea di pensiero corrisponde a quello che gli altri stanno vedendo / facendo là fuori? O c'è un modo più elegante per farlo? Ho pensato di implementare qualcosa come Open ID, ma sembra un po 'eccessivo per i nostri bisogni. Voglio che questo sia il più semplice possibile in modo da poter documentare il processo e altri team di sviluppatori possono sviluppare app che si collegano al sistema di autenticazione senza richiedere troppa assistenza.

    
posta Rocket04 16.02.2017 - 16:43
fonte

2 risposte

5

Non essere pazzo. Nessuno sano di mente tenterebbe di scrivere qualcosa del genere da zero. Usa OAuth. Puoi utilizzare le specifiche del token JWT Bearer per il token e utilizzare gli ambiti per determinare a quale app o risorsa l'utente può accedere. Questa non è una buona area per iniziare a reinventare la ruota!

    
risposta data 18.04.2017 - 18:38
fonte
0

Recentemente ho appena seguito una guida qui che spiega il processo di installazione per l'autenticazione basata su token. Un modo in cui posso immaginare di passare una qualche forma di identificazione specifica per app sarebbe utilizzare le attestazioni.

Quindi hai il sito web A che ti reindirizza alla pagina del tuo sistema di login. Il sito Web A ha anche trasmesso altri dati come dove portare l'utente dopo il login e dove si trova il sito A. Il tuo sistema di autenticazione esamina questi dati e usa un interruttore di qualche forma per aggiungere un reclamo al token dell'utente che identifica il loro ambito di applicazione corrente.

Inoltre, aiuta a combattere l'utente che cambia app molto velocemente e continua ad accedere alle risorse dell'app per app1 mentre su app2 fa scadere i tuoi access_tokens molto velocemente. Nel mio sito demo in esecuzione costruito utilizzando la guida di cui sopra, la scadenza scade ogni minuto, così come l'implementazione di un refresh_token rende tutto più semplice. Un altro passaggio che potrebbe essere utile è che l'aggiunta di rivendicazioni agli utenti aggiunga anche un ruolo a tale utente affermando che si trovano su un sito Web.

Quindi su app1 / api / endpoint / getData imposta [Authorize (Roles="App1")], questo assicurerà che solo access_tokens che contengono un ruolo = App1 possa usare quell'endpoint all'interno del tuo javascript o qualunque script lato client l'utente utilizza semplicemente controlli logici per errori come l'impossibilità di accedere a un endpoint specifico e forse l'utente deve ottenere un nuovo access_token utilizzando il token di aggiornamento e così via e così via.

Usando la stessa guida che ho elencato sopra, segui quel link e cerca questo:

var identity = new ClaimsIdentity(context.Options.AuthenticationType);

Come puoi vedere, l'identità sta aggiungendo affermazioni che sono fondamentalmente solo valori che verranno incapsulati all'interno di access_token.

Ora, quando un utente chiama nella tua web API che ha un attributo autorizzato sopra di esso, fai semplicemente un controllo sulle richieste degli utenti.

Un esempio di questo può essere trovato qui .

    
risposta data 17.02.2017 - 16:51
fonte

Leggi altre domande sui tag