Utilizzo di JTWs nell'implementazione OAuth

Question

Utilizzo di JTWs nell'implementazione OAuth

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

2

Attualmente sto creando un'API con cui comunicare un'app. Gli endpoint di API verranno protetti, quindi mi piacerebbe utilizzare un flusso OAuth con JWT per la sicurezza. Il mio flusso andrà in questo modo:

Ricevi e convalida le credenziali dell'utente
Emettere un token di accesso (JWT) e aggiornare il token per le credenziali valide
Verifica l'integrità del token di accesso quindi verifica la scadenza
- Se scaduto - invia un 401 e si aspetta di ricevere un token di aggiornamento che verrà quindi convalidato e verrà emesso un nuovo token di accesso
- Altrimenti utilizza la rivendicazione ID utente per raccogliere più contesto e continuare con la richiesta \

Le mie domande:

Integrità JWT: un JWT compatto è composto da tre parti: intestazione, payload e firma. La firma viene verificata applicando il alg specificato nella sezione dell'intestazione all'intestazione codificata base64url e alle sezioni del carico utile separate da un '.' e quindi base64url codifica il valore prodotto. Questo significa che è possibile creare un token di accesso fasullo? Un token di accesso rubato potrebbe essere non codificato, l'ID utente rubato e inserito in un token di accesso molto simile, ma falso. Questo falso token viene quindi firmato come un normale JWT. Quando il server riceve questo token di accesso, questo token non mantiene la sua integrità?
Flusso OAuth: Questo sembra essere un flusso corretto? I token di aggiornamento di un utente verranno archiviati in un database in modo che possano essere verificati in futuro (questi avranno una lunga durata ). Il token di accesso si baserà sulla sua integrità e sulle informazioni contenute al suo interno dal momento che la sua durata è così breve.

api authentication oauth jwt

posta Gavin 23.11.2016 - 01:20

fonte

2 risposte

0

Integrità JWT : se utilizzi una chiave simmetrica per firmare il tuo token e questa chiave viene rubata, la risposta alla tua prima domanda è: SÌ. Tuttavia, se si utilizza la crittografia asimmetrica, è possibile firmare il token con la chiave privata (memorizzare questa chiave privata in un luogo sicuro) e inviare il token all'utente (utilizzare TLS tra client e server). La firma viene applicata all'intero token, quindi se un utente malintenzionato ottiene il token, non può manometterlo perché non conosce la chiave privata utilizzata per rassegnare l'intero token.

Flusso OAuth : Sì.

risposta data 23.11.2016 - 10:55

fonte

Leggi altre domande sui tag api authentication oauth jwt

Esistono meccanismi per precaricare il blocco della chiave pubblica HTTP Rileva un host sulla mia rete che sta eseguendo il Web Scraping su sistemi esterni

score 2 · Accepted Answer

Does this seem to be a proper flow?

Non vedo niente di sbagliato in questo. Prenditi cura della parola 'flusso', tuttavia, ha un significato specifico quando parli di OAuth, e stai annotando di usarlo in base a cosa significa "flusso OAuth".

Does this mean it is possible to create a phony access token?

Per poter firmare una JWT, devi conoscere un segreto. JWT supporta le firme tramite HMAC (che richiede un semplice segreto precondiviso) o con crittografia a chiave pubblica [1]. Tutti i fornitori di oauth con cui ho lavorato, in particolare Google e Microsoft, utilizzano la crittografia a chiave pubblica (RSA) per creare la firma digitale.

Quindi, l'attacco che descrivi dipende dall'attaccante che ha accesso alla chiave privata dell'istituzione che ha firmato il JWT. L'accesso alla chiave pubblica non è sufficiente; puoi usare questo per verificare se la firma è valida, ma non puoi usare la chiave pubblica per firmare nuovamente un token modificato.

Se il JWT in questione utilizzava la semplice hmac invece della crittografia a chiave pubblica per creare la firma, allora sia il firmatario che la parte che aveva bisogno del segreto per verificare la firma sarebbero in grado di firmare correttamente un JWT alterato. Ma in quel caso, se il token di accesso fosse stato rubato, il ladro non avrebbe ancora avuto il segreto. Vedo solo il possibile pericolo quando la persona a cui è destinato il token di accesso lo modifica intenzionalmente e lo abbandona usando il segreto condiviso. Non sono sicuro di quali potrebbero essere le implicazioni sulla sicurezza di un simile attacco, ma suppongo che questo sia il motivo per cui i grandi provider di OAuth utilizzano la crittografia a chiave pubblica.

[1] link