Memorizzazione di accesso OAuth e aggiornamento dei token in cookie non HttpOnly

Question

Memorizzazione di accesso OAuth e aggiornamento dei token in cookie non HttpOnly

#1 da (2 voti)
#2 da (0 voti)

1

Sto utilizzando il flusso del codice di autenticazione OAuth per generare accesso e aggiornare i token e quindi li memorizzo in due cookie del browser che sono not HttpOnly e che li inviano anche al client.

I cookie devono essere non HttpOnly perché il client deve sapere se esiste un token di accesso per sapere se deve parlare con il server di autorizzazione ed eseguire un flusso di token di aggiornamento per ottenere nuovi token.

Quanto è grave questa sicurezza? Quali sono i rischi quando il token di aggiornamento / accesso viene rubato? Quali sono alcuni modi per mitigare questi rischi?

Modifica

Inoltre, pensi che PKCE possa migliorare in qualche modo la sicurezza del token di aggiornamento? Da quanto ho capito, può solo migliorare la sicurezza del flusso del codice di autenticazione ma dopo aver ottenuto un token di accesso + aggiornamento non è molto diverso, non è necessario utilizzare un segreto quando si scambia il token di aggiornamento per una nuova coppia di token . Grazie

cookies oauth2

posta Michael 13.09.2018 - 13:41

fonte

2 risposte

Leggi altre domande sui tag cookies oauth2

Cookie di conformità PCI Scan & Globalscape EFT Web App non contrassegnati sicuri Viaggio in Cina: protezione di telefono e laptop

score 2 · Answer 1

L'elemento principale del rischio è da XSS. Se nell'applicazione è presente un XSS, può essere utilizzato per rubare banalmente i token.

Non appena un tale token viene rubato, l'utente malintenzionato può impersonare completamente l'utente.

Ciò che non è chiaro per me è il motivo per cui è necessario avere questi cookie disponibili al di fuori di HTML: non puoi usare un altro cookie per memorizzare l'elemento pubblico del cookie (forse l'intero carico utile o semplicemente la scadenza e tutto ciò di cui hai bisogno per il tuo cliente per capire se ha bisogno di andare al portale di autenticazione) e mantenere i token JWT in cookie solo HTTP?

score 0 · Answer 2

Penserei a lungo e duramente di avere un client di aggiornamento disponibile sul lato client senza alcuna protezione. Per un'app lato server in genere lo si archivia in un cookie HTTPS protetto (cioè crittografato e firmato).

Per un'app lato client come quella che descrivi in Open ID Connect devi utilizzare il flusso implicito (nessun token di aggiornamento) e per rinnovare devi utilizzare una chiamata prompt=none silenziosa all'endpoint di autorizzazione per ottenere una nuova (breve vissuto) token di accesso. Questo scenario è ancora vulnerabile a XSS poiché il token di accesso verrà archiviato nella memoria locale o di sessione o simile, ma non sarà disponibile alcun token di aggiornamento.

Sei in grado di utilizzare OIDC con il tuo IDP?