OpenID Connect: come mantenere un'esperienza single sign-on tra più client Web della stessa applicazione ombrello?

0

Sto prendendo in considerazione come adottare un'applicazione multilivello piuttosto complessa con più app Web che delegano di nuovo allo stesso server applicazioni e la migrazione per utilizzare l'autenticazione OIDC con il flusso di codice di autenticazione. Sto anticipando l'utilizzo di identity server 4.

La mia domanda è: quale sarebbe la migliore prassi accettata in termini di mantenimento di un'esperienza single-sign-on tra queste diverse applicazioni web client (ad esempio, i segni dell'utente in uno, ha firmato tutto fino a quando non firma). p>

Il link suggerisce:

Note that the audience (aud claim) of the [id token] is set to the client's identifier, which means that only this specific client should consume this token.

Questo suggerisce che dovrei considerare il mio server di applicazioni back-end come il mio singolo 'client' e le mie app web condividono lo stesso ID client. Posso immaginare di farlo memorizzando il token ID browser in un cookie sicuro.

Il link sembra convalidare questa idea:

Put into a browser cookie the ID token can be used to implement lightweight stateless sessions.

Ma mi chiedo se sia la migliore prassi di sicurezza per mantenere un id_token in un cookie.

Mi chiedo se ci sono altri approcci, come:

  • Considerando ogni applicazione Web un "client" separato
  • Quando l'utente accede a una seconda applicazione Web, fa in modo che vengano indirizzati direttamente al provider OIDC, che creerebbe automaticamente un token client per il nuovo client in base all'idea che siano ancora fondamentalmente "connessi" al OP.

Sembra che questo debba essere un problema risolto. Qual è la migliore pratica accettata qui?

    
posta 10.01.2018 - 07:28
fonte

1 risposta

1

In pratica ottieni SSO fuori dalla scatola con IdSrv4. Una volta effettuato l'accesso a IdSrv, il browser invierà il cookie IdSrv insieme a ciascuna richiesta a IdSrv. Quindi, quando la tua prima app web invia una richiesta di autenticazione, ti verrà chiesto di autenticare a livello di IdSrv - in quel momento, viene creato quel cookie di autenticazione e (a seconda del flusso che stai utilizzando) un codice e / o token sono restituito alla tua app cliente. Quando la tua seconda app Web invia una richiesta di autorizzazione a IdSrv, il browser invia oltre il cookie auth insieme a tale richiesta, quindi sarai ancora autenticato a livello di IdSrv (supponendo che il cookie non sia scaduto) - codice e / o token verranno automaticamente essere restituito al secondo client senza che l'utente debba fornire nuovamente le proprie credenziali.

Vorrei sconsigliare il riutilizzo dello stesso ID client (e quindi del client secret) in varie app Web: nel caso in cui il client secret sia esposto per una app Web, è esposto a tutti, e questo è qualcosa da evitare.

Il token di identità è in genere molto di breve durata - l'unica ragione per cui aggrapparsi a esso (dopo averlo utilizzato per l'autenticazione a livello dell'app client) è passarlo all'endpoint di endession come id_token_hint quando si esegue la registrazione su.

Spero che questo aiuti:)

    
risposta data 29.01.2018 - 18:39
fonte

Leggi altre domande sui tag