2014-12-08 18 views
6

Vorrei utilizzare un server OpenID Connect (OIDC) self-host in combinazione con JWT come token di autorizzazione (token di accesso in termini OIDC). JWT verrebbe utilizzato per proteggere i servizi REST mentre l'interfaccia utente è un mix di applicazioni classiche e di una sola pagina (Angolare). In questo modo, lo strato resto sarebbe in grado di fare l'autorizzazione basate su una JWT apolidi in modo gettone non sono necessarie connessioni in più DB, come descritto qui:OpenID Connect con token JWT stateless

https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/

Per una pagina singola applicazione, OIDC flusso implicito è adeguata. Tuttavia, vedo un problema di sicurezza quando Implicit Flow viene utilizzato in combinazione con token JWT stateless: i token vengono consegnati come parte di un frammento nell'URL, il che significa che non è possibile rimuoverli (sono facilmente disponibili nella cronologia del browser) né invalidare loro (sono apolidi) -> nessun logout possibile.

vedo 2 opzioni per mitigare questo:

  1. utilizzare una molto breve durata gettoni (max fino a diversi minuti). Ciò potrebbe drammaticamente ostacolare l'usabilità.
  2. Utilizzare un flusso di codice di autorizzazione tramite AJAX. Questo è non compatibile con OIDC ma farebbe un logout possibile poiché i token non verrebbero esposti nell'URL.

La terza opzione consiste nel rinunciare a token JWT stateless e utilizzare token al portatore semplici con assegni DB.

Mi manca qualcosa? Cosa sceglieresti?

risposta

1

si può sostenere circa il rischio di frammenti di finire in cronologia del browser, ma "semplici" gettoni portatore opachi sarebbero soggetti alle stesse limitazioni che descrivi per JWT gettoni

utilizzando un flusso di codice con AJAX è certamente non è impedito dalla specifica OpenID Connect, quindi è possibile utilizzare proprio questo; il flusso implicito è solo una raccomandazione per i client in-browser poiché ottimizza il numero di round-trips per ottenere un token all'agente utente

+0

I token bearer opachi semplici potrebbero essere esplicitamente revocati dall'utente, almeno in teoria. Nella vita reale, tuttavia, è improbabile. –

+0

d'accordo, ma il mio punto era circa ma loro finiscono nella cronologia del browser allo stesso modo dei token JWT, con la possibilità che vengano riutilizzati prima di essere revocati (immagina di chiudere il browser o addirittura di bloccarlo) –