Come strutturare correttamente JWT

Question

Come strutturare correttamente JWT

#1 da (3 voti)

1

Sto progettando un flusso di lavoro di autenticazione JWT per un'API RESTful che utilizza due tipi di token:

Token telefono , token di breve durata - emesso completando una richiesta di password One-Time. Il suo compito è dimostrare la "proprietà" di un telefono. Porta il numero di telefono.
Token di accesso , token di lunga durata - emesso fornendo un token telefonico valido. Il suo compito è fornire l'identità del proprietario del telefono. Trasporta l'ID dell'utente.

Lamiadomandaècomestrutturarecorrettamentequeiduetokenesedovreiusareduechiavidifirmadistinteperloro?

Daquantohocapitol'oggetto(sub)deltokentelefonicodovrebbeessereilnumeroditelefonoel'oggetto(sub)deltokendiaccessodovrebbeesserel'IDdell'utente.(Modifica:nonnesononemmenosicuro,comepotrebbeilcontrollersaperecomeinterpretareilnumero,ovverocercarelarisorsagiusta?Nonsarebbemegliousarestringhecome"phone" e 'identità' per l'oggetto e fornire un campo 'id' aggiuntivo?)

E il campo emittente ( iss ), dovrebbe essere qualcosa come http://example.com/phone e http://example.com/identity ?

E il campo pubblico ( aud )? Il token del telefono ha un piccolo pubblico, cioè solo uno o due servizi, dovrei specificarli esplicitamente? Mi piace aud: ['identity', 'xyz'] ?

In caso di token di accesso il pubblico è abbastanza ampio, cioè molti servizi che consumano questo token, e il pubblico potrebbe crescere quindi non voglio hardcode nel token, altrimenti dovrei rilasciare nuovi token ogni volta che aggiungo un servizio. Come potrei aggirare questo?

Sarei molto felice se potessi suggerire una possibile struttura e il ragionamento che ci sta dietro.

design security authentication json web-services

posta sled 10.09.2016 - 03:44

fonte

1 risposta

Leggi altre domande sui tag design security authentication json web-services

Transazione con carta di credito attivata da Geofence Come utilizzare Delphi BPL da Visual C ++

score 3 · Accepted Answer

Divulgazione : risposta fornita da un tecnico Auth0.

Vorrei mettere in discussione la necessità di due token perché non vedo un requisito rigoroso per entrambi. Ciò che hai presentato suona molto simile a un meccanismo di autenticazione senza password basato sugli SMS e il risultato di una procedura di autenticazione è una cosa normale che dimostra che identità di un utente.

Vedi anche Autentica gli utenti con un codice monouso via SMS in una SPA per alcuni diagrammi di sequenza che copre questo flusso di autenticazione senza password.

Avere solo un token come risultato risponde immediatamente alla maggior parte delle tue domande:

Solo una chiave di firma di cui preoccuparsi
Solo un emittente di token per nominare
La rivendicazione sub nel token farà riferimento all'identità a cui il token è associato

Ora che hai un token che dimostra l'identità di un utente, devi prendere alcune decisioni di autorizzazione. Qui è dove entrano in gioco i token di accesso, specialmente quando sono coinvolte le API REST. L'utilizzo di un token di accesso al portatore per autenticare le chiamate in un'API HTTP è davvero molto semplice da configurare, dato che devi solo passare il token, l'API lo convalida e il gioco è fatto.

Il problema più complesso è come vengono rilasciati i token di accesso ... è possibile riutilizzare il token che dimostra l'identità dell'utente e in scenari semplici è possibile convivere con questo. Tuttavia, in scenari complessi con più API in cui l'accesso a uno non implica l'accesso ad altri e / o ci sono autorizzazioni a grana fine, è necessario prendere decisioni che diventino più confuse. Uno dei punti di cautela è quello che hai citato, al fine di prevenire possibili attacchi in cui un token rilasciato all'API A viene quindi provato contro l'API B, ogni API dovrebbe verificare che il token sia stato effettivamente rilasciato a loro, nel caso di JWT , questo viene fatto controllando la dichiarazione di aud così la pratica corretta per elencare tutti i destinatari di il token.

Considerando che omettere il pubblico non è una buona scelta, ritengo di non avere molti spettatori in primo luogo e di trovare una strategia per raggruppare le API (se ne hai davvero tante) sotto una designazione del pubblico.

Tutto ciò presuppone anche che tu voglia utilizzare token di accesso autonomo (il formato JWT sarebbe probabilmente il migliore). Potresti invece utilizzare token opachi di riferimento che implicherebbero la necessità di archiviare le informazioni associate altrove e interrogarle ogni volta che vuoi convalidare un token.