Pattern aziendali per l'autenticazione JWT per applicazioni basate su REST?

La specifica JWT descrive solo il payload e il modo in cui viene inviato, ma lascia aperto il protocollo di autenticazione, che consente la flessibilità, ma sfortunatamente, la flessibilità può portare a antipattern e errori di progettazione.

Sto cercando alcuni schemi aziendali ben ponderati e testati per l'autenticazione JWT, che potrei usare o adattare, ma non sono riuscito a trovare qualcosa di completo.

Quello a cui stavo pensando è:

• quando non viene soddisfatta alcuna intestazione di autorizzazione o il token JWT non è valido o è scaduto, inviare HTTP 401
• per autenticare, utilizzare / accedere al canale REST, inviare nome utente e password come oggetto JSON
• per mantenere attivo il token, utilizzare il canale REST / keepalive, chiamarlo ogni N (5) minuti, ricevere il nuovo token JWT e sostituire quello esistente dopo ogni chiamata (il token scade dopo M (15) minuti)

Tuttavia, ciò che mi disturba è la necessità di quel canale / keepalive. D'altra parte, mi costringe a impedire che l'autenticazione scada, anche se l'utente è assente (la decisione, se vorremmo che keepalive non sia ancora soddisfatta) e, naturalmente, si tratta di chiamate extra e complicazioni extra al protocollo. Ciò che sarebbe interessante è che quel server prolunga automaticamente il token. In un ambiente basato sulla sessione, ripristina il timestamp, qui, tuttavia, il server dovrebbe inviare un nuovo token, forse non ogni volta, ma una volta che il token scadrà tra R (diciamo, 10) minuti. Metterlo nel corpo della risposta significherebbe modificare il protocollo di risposta JSON (quindi la soluzione è invasiva e non trasparente) e inserire un'intestazione HTTP aggiuntiva che il client potrebbe elaborare non potrebbe essere necessariamente un buon modello. IO'

Ci sono schemi aziendali pronti che rispondono ai miei punti in sospeso? La mia bozza di protocollo è un'idea affidabile? Preferirei usare qualcosa di pronto rispetto al design da zero.

JWT ( Introduzione al token Web JSON ) è solo un formato token, l'autenticazione è qualcosa che non rientra nell'ambito di tale specifica. Viene infatti comunemente utilizzato nei sistemi di autenticazione, ma è possibile utilizzarlo anche per scenari completamente diversi, quindi ha senso non includere vincoli specifici di autenticazione all'interno di tale specifica.

Se stai cercando una guida per l'autenticazione, dovresti fare riferimento alla famiglia di specifiche OpenID Connect . Inoltre, se il tuo sistema è composto da API HTTP e sei interessato a fornire l'accesso delegato a tale API alla tua o all'applicazione client di terze parti, devi fare riferimento alla specifica OAuth 2.0 .

Esistono protocolli aggiuntivi relativi all'autenticazione come SAML e WS-Federation che sono ancora ampiamente utilizzati negli scenari aziendali, ma sono significativamente più complessi da implementare.

Informazioni sui punti aperti specifici:

• Lo schema di autenticazione token al portatore è definito in RFC 6750 che contiene le istruzioni su come eseguire le richieste e i possibili codici di errore .
• OAuth2 e OpenID Connect contemplano entrambi la possibilità e definiscono il modo di scambiare un nome utente / password con un token.
• Il problema dell'estensione della durata di un token autonomo / per valore (JWT) viene risolto all'interno di OpenID Connect e OAuth2 mediante i token di aggiornamento .

Sebbene OAuth2 e OpenID Connect possano essere visti come più facili da implementare rispetto ad alcuni dei suoi predecessori, sono ancora abbastanza complessi da giustificare un po 'di cautela e implementarli solo se si è disposti a spendere una notevole quantità di tempo e risorse. In genere è un'opzione migliore per utilizzare librerie o servizi di terze parti che fanno questo lavoro pesante per te.

Infine, questi protocolli coprono molti scenari, quindi potrebbero essere eccessivi in ​​alcune situazioni.

Non penso che tu abbia bisogno di un canale keepalive. Il payload può (e si consiglia di) contenere le informazioni di scadenza fornite dal server (nella expchiave, secondo lo standard ) quando il token viene generato al momento dell'accesso. Se viene utilizzato un token scaduto (che, ovviamente, è determinato dal server, che confida nel token solo se la firma viene convalidata), il server lo rifiuta semplicemente con HTTP 401, chiedendo al client di riautenticare.

I clienti, nel frattempo, possono essere proattivi. La sezione del payload non è crittografata e, dal momento che il client può leggerlo, il cliente può verificare quando una richiesta verrà inviata con un token scaduto e quindi chiamare /loginnuovamente se il token è scaduto.

In alternativa, REST consente l'invio di informazioni ipermediali come "motore di stato", e quindi se lo desideri, puoi effettivamente rendere il tuo JWT monouso e con una scadenza. Ogni richiesta, quindi, genererebbe un nuovo JWT che viene restituito nella risposta al client, nel contenuto o più probabilmente in un'intestazione di risposta, come hapi-auth-jwt2 .