Penso di averlo risolto, ma mi piacerebbe sentire se sbaglio. Abbiamo un insieme di app Python + Angular.js, che utilizzano token JWT per l'autenticazione, in cui i token vengono crittografati utilizzando una chiave segreta, il payload identifica l'utente e il token è memorizzato sul lato client in un set di cookie come SOLO HTTP e altrettanto sicuro. Per una serie di motivi questo funziona bene per noi, possiamo usare una app Python wsgi middleware su più backend API, il nostro token viene inviato automaticamente su ogni richiesta al dominio, e possiamo bypassare l'utilizzo completo delle sessioni. Ho avuto questa parte di controllo qui e altrove e sono fiducioso che sia buono. (la mia domanda è qui: link )
La mia nuova domanda è come gestire i token CSRF, dato che non stiamo usando affatto le sessioni. Sto pensando quanto segue:
- auth viene gestito dal token jwt nel cookie sopra descritto, chiamiamolo accept_token_cookie. JS non può leggerlo, è solo HTTP. Ha l'id utente
- viene inviato un secondo cookie con il nostro token CSRF, che non è HTTP_ONLY, quindi angular può leggerlo (chiamiamolo csrf_cookie)
- il carico utile csrf_cookies è una crittografia del nostro carico utile dell'identità (o parte di esso, come l'email dell'utente), ma realizzata con una seconda chiave segreta
- quando viene effettuata una richiesta XHR, il mio JS guarderà il valore csrf_cookie e lo aggiungerà a un'intestazione
- in ingresso, il nostro server decodifica entrambi i cookie e ottiene il token inviato da angular in un'intestazione personalizzata. Se questi non corrispondono tutti, sappiamo che questa richiesta non è buona perché il javascript richiedente non può leggere il nostro csrf_cookie. Tuttavia, csrf_cookie non è ancora utilizzato per generare identità, che è ciò che vogliamo in modo che il cookie accept_token rimanga totalmente opaco al client.
Da quanto ho letto, quanto sopra sembra corretto. Se ho torto, per favore dimmi perché, grazie.