Token Web Token. Intestazioni di denominazione di convenzioni, formattazione e problemi di sicurezza

Question

Token Web Token. Intestazioni di denominazione di convenzioni, formattazione e problemi di sicurezza

#1 da (0 voti)

2

Ho implementato il mio schema di autenticazione e autorizzazione JSON Web Tokens, basato su tre token: token di accesso, token di riferimento e token di aggiornamento. Sono generati dal back-end o dal codice dell'applicazione e tutta la logica di autorizzazione è implementata nel middleware (nel codice Lua incorporato in nginx).

Queste sono alcune domande che mi infastidiscono:

Dovrei firmare il mio token di riferimento con RSA prima di passarlo al client?
Dovrei firmare il mio token di aggiornamento con RSA? Ovviamente, come il token di riferimento, non memorizza alcuna informazione critica e quindi non ne sono sicuro.
Devo firmare il mio token di accesso con RSA, se non viene mai passato al client e viene utilizzato solo sul lato server? Immagino, dovrei, proprio come nel caso delle password hash memorizzate nel database.
Quali sono le convenzioni di denominazione per l'intestazione HTTP in cui passo il mio token di riferimento dal server al client? Va bene usare solo un'intestazione arbitraria come X-Reference-Token ?
In quale intestazione dovrei passare il token di riferimento dal client al lato server? Dovrei usare Authorization: Bearer ... (sembra una convenzione standard) o è giusto usare lo stesso X-Reference-Token: ...
È sicuro (suppongo, non) di passare il token di aggiornamento al client. E se no, come lo memorizzano? Il token di riferimento è archiviato nei cookie lato client e passato con ogni richiesta dal client al server, il token di accesso non viene mai passato al client e viene memorizzato nella cache lato server e dove dovrei memorizzare il mio token di aggiornamento?
È sicuro utilizzare il valore di token di riferimento non elaborato come chiave, con cui ottengo il token di accesso dalla cache lato server? Diciamo che il mio token di riferimento è solo un GUID, è abbastanza sicuro da usare questo stesso GUID come chiave con cui è memorizzato il mio token di accesso? O è più sicuro ottenere questa chiave dal GUID di alcune trasformazioni?

jwt

posta Jacobian 17.08.2017 - 21:33

fonte

1 risposta

Leggi altre domande sui tag jwt

Come utilizzare il mapping personalizzato JAXB per istanziare classi istanziabili su XML Meccanismo di autenticazione senza inviare password sul lato server

score 0 · Accepted Answer

Ci sono molte incognite qui, ma qui è la mia risposta alla risposta basata sulle migliori pratiche di sicurezza generali.

Should I sign my reference token with RSA before I pass it to the client?

Le firme possono essere utilizzate per autenticità, integrità e non ripudio. In questo caso, l'integrità è l'unica che sembra avere un senso. Se è necessario, devi assolutamente firmare il token. È necessario, se il token è auto-descrittivo, cioè contiene dati che possono essere manipolati dal client (come un JWT). Ho scritto post del blog sull'integrità. RSA potrebbe non essere richiesto. Un semplice HMAC potrebbe essere sufficiente per te. Il tuo caso d'uso determina in realtà se hai bisogno di crittografia asimmetrica qui.

Should I sign my refresh token with RSA? Obviously, like reference token, it does not store any critical information and therefore I'm not sure of that.

Vedi 1. Poiché non lo si passa al client e sembra essere un token opaco. Puoi farcela senza firmare questo.

Should I sign my access token with RSA, if it is never passed to the client and is only used on server side? I guess, I should, just like in case of hashed passwords stored in database.

Vedi 1. Non passarlo al client, rendere impossibile la modifica da parte del client. L'integrità può ancora essere richiesta, dipende dal tuo caso d'uso.

What are naming conventions for HTTP header in which I pass my reference token from server to the client? Is it ok to use just some arbitrary header like X-Reference-Token?

Sì, va bene. Dato che lo schema è personalizzato, non penso che ci sia male nell'usare un'intestazione personalizzata per un pezzo di token personalizzato.

In what header should I pass reference token from client to the server side? Should I use Authorization: Bearer ... (it seems like a standard convention) or is it ok to use just the same X-Reference-Token: ...

Autorizzazione: probabilmente Bearer è meglio qui. Tuttavia, sembra che in 6. tu stia utilizzando i cookie per il token di riferimento, nel qual caso non è necessaria un'intestazione aggiuntiva per inviarlo.

Is it secure (I guess, not) to pass refresh token to the client. And if not, how do they store it? Reference token is stored in client side cookies and passed with each request from client to the server, access token is never passed to the client and is stored in server side cache and where should I store my refresh token?

Il tuo schema è una scatola nera per me, ma sembra che il token di accesso non colpisca mai il client, quindi il token di aggiornamento non dovrebbe neanche. In un normale meccanismo di autenticazione come OAuth, questi due token richiedono la stessa quantità di sicurezza. Senza contare il fatto che i token di aggiornamento durano più a lungo.

Is it secure to use raw reference token value as a key, by which I get access token from server side cache? Let's say, my reference token is just some GUID, is it secure enough to use this very GUID as a key by which my access token is stored? Or is it more secure to get this key from GUID by some transformations?

Di nuovo il tuo schema è una scatola nera. Mi sembra che il tuo token di riferimento sia in realtà un ID di sessione. In tal caso, non dovrebbe essere un GUID, ma un token opaco casuale, come descritto qui . Va bene memorizzare l'ID di sessione come chiave per ottenere il token di accesso dalla cache.

Qualunque cosa ho descritto sopra si basa sulla mia comprensione molto limitata del tuo schema. In generale, non si dovrebbe eseguire il proprio schema di autenticazione / autorizzazione. Mi sembra che tu abbia un'applicazione web con gestione delle sessioni che utilizza i cookie e un OAuth per accedere ad alcune risorse sul back-end.

Dai un'occhiata a OAuth, potrebbe benissimo semplificarti un po 'la vita.