autenticazione JWT o cookie?

Motivi per selezionare JWT:

• Non richiede al server di mantenere uno stato, ovvero non è necessario effettuare ricerche costose su ogni richiesta.
• Più facile condividere l'autorizzazione su domini diversi.

Motivi per scegliere i cookie di sessione:

• Più facile da implementare in molte lingue e framework (ad es. PHP).
• revoca dell'autorizzazione immediata, ad es. la registrazione di un utente è possibile. Anche con un sistema di token più complesso, la revoca non è istantanea se usi JWT.

Quando fai qualcosa per simpe per pochi utenti in PHP, non hai bisogno dei vantaggi del JWT. Dato che PHP viene fornito con un'implementazione esistente di sessioni, lo userei per evitare la complessità inutile. Ma per un progetto diverso con esigenze diverse la risposta può essere diversa.

Usa entrambi. Prendi alcune misure per prevenire il furto di identità.

Ok, ma parliamo di come farlo.

JWT è non un sostitutivo per i cookie. Non potrebbe essere, in quanto hanno scopi diversi.

In un'app web (ad esempio, non un api web), i cookie sono ancora il più sicuro e il migliore in assoluto per trasportare le credenziali su HTTPS. In effetti, esiste almeno un altro modo consolidato per memorizzare le credenziali. È l'intestazione di autorizzazione HTTP. Il problema con le intestazioni di autorizzazione in un'app Web è che saranno disponibili per lo scripting lato client e, quando è richiesta una sessione a lungo termine, sarà necessario archiviare le credenziali da qualche parte. Non c'è un modo sicuro per farlo nei browser. Quindi le intestazioni di autorizzazione sono le migliori utilizzate in web apis consumate sul lato server.

Tradizionalmente, un cookie di sessione memorizza solo un puntatore ai dati memorizzati da qualche altra parte . Un server dovrebbe decodificare il cookie e quindi recuperare i dati a cui punta. Per i sistemi di grandi dimensioni, viene utilizzato un database di cache o di sessione per evitare di legare l'utente a un singolo server. Ora entra in JWT.

JWT è un formato di messaggio che può contenere tutte le informazioni necessarie al server per elaborare le richieste, come identificare l'utente. Salva il server dall'eseguire una richiesta per recuperare ulteriori dati. Il carico utile completo è firmato e inviato insieme al messaggio per confermare che è valido. Non è un hash né è un segreto, quindi nessuna informazione sensibile dovrebbe andare lì . Ora, abbiamo ancora bisogno di un mezzo per trasportare il JWT tra server e amp; browser. Un cookie Sicuro , Http Only si adatta come un guanto.

I sistemi di maggiori dimensioni traggono vantaggio da JWT perché qualsiasi server può soddisfare una richiesta , a differenza di un cookie di sessione di solito (a meno che come detto sopra) legato a un singolo server.

Ci sono altri pro e amp; cons contro per ciascuno come affermato da Anders nella sua risposta, non ho intenzione di ripeterlo dappertutto.