La mia API REST può consegnare token Web JSON alla mia app. I token danno all'app l'opportunità di scaricare i file in una fase successiva. I file da scaricare sono identificati da un UUID.
L'UUID del file è memorizzato in sub all'interno del token. Non voglio che un token sia in grado di essere utilizzato in natura, quindi cambio solo il token per un URL di download se l'uuid è anche inviato come parametro all'API
I miei JWT sono crittografati con H256.
La domanda: È considerato negativo incorporare una stringa conosciuta (l'UUID) nel token crittografato?
Se è una cosa negativa, qual è il concetto corretto di "legare" un token a un certo contesto esterno?
Modifica:
Dopo aver scritto la mia domanda, penso di vederlo un po 'più chiaro. Mi piacerebbe sapere dalle competenze su questo. Ma questa è la mia opinione per ora:
- Il rischio è probabilmente piccolo, ma non necessario.
- Ho già l'ID utente registrato nel token di download
- Anche l'id utente viene inviato con ogni richiesta in un altro token (il token di autenticazione acquisito al momento dell'accesso)
Quindi, non invierò più l'UUID come parametro di testo libero. Invece lego il token di download all'utente connesso confrontando l'id utente dal token di autenticazione con l'id utente nel token di download.
Altre modifiche:
La piccola, ma illuminante domanda di Elias "Cos'è la crittografia H256" mi ha fatto ricordare che i JWT non sono crittografati, ma firmati. Permette anche al mio newbie sicurezza gloria di brillare attraverso ..
Penso di stare bene solo con la segnaletica, poiché non invio informazioni sensibili nel token. La mia prima domanda dovrebbe essere riformulata (ho cambiato la domanda).
Sarebbe più facile per qualcuno impossessarsi della mia chiave segreta di firma se un UUID noto fosse incorporato nel payload firmato?