Sono d'accordo che la denominazione dei diversi concetti sia confusa. Quando si parla di autenticazione in un contesto web, ci sono diversi aspetti da considerare.

Quali informazioni invia il client durante l'autenticazione?

• Un ID di sessione . Ciò significa che il server ha una memoria di sessione che contiene le sessioni attive. Le sessioni sono stateful sul lato server.
• Un insieme di attestazioni . I reclami contengono informazioni su quali operazioni il cliente può eseguire. Il server non tiene traccia di ogni client autenticato, ma si fida delle affermazioni. I reclami sono in genere stateless sul lato server.

In che modo il client invia le informazioni di autenticazione?

• Cookie . I browser inviano automaticamente i cookie ad ogni richiesta, dopo che il cookie è stato impostato. I cookie sono vulnerabili a XSRF.
• Altre intestazioni . In genere, per questo si utilizza l'intestazione Autorizzazione. Queste intestazioni non vengono inviate automaticamente dal browser, ma devono essere impostate dal client. Questo è vulnerabile a XSS.
• URL richiesta . Le informazioni di autenticazione sono incluse nell'URL. Questo non è comunemente usato.

Qual è il formato delle informazioni di autenticazione?

• Testo normale senza segno . Questo può essere usato per gli ID di sessione. Un ID di sessione non è generalmente ipotizzabile dal client, quindi il server può fidarsi del fatto che il client non lo abbia forgiato.
• Token Web Jono . Le JWT sono firmate crittograficamente e contengono informazioni di scadenza. Di solito il client può decodificare il token, ma non può modificarlo senza che il server se ne accorga.
• Qualsiasi altro formato firmato . Come i JWT. L'importante è la firma crittografica, che impedisce al client di alterare i dati.

Bonus: come fa il cliente a memorizzare le informazioni localmente

• Cookie . Questo è ovviamente il caso quando si utilizzano i cookie per trasmettere le informazioni. Ma i cookie possono anche essere utilizzati come meccanismo di archiviazione lato client. Ciò richiede che il cookie sia leggibile dagli script per essere utile. Ad esempio, un client può leggere il cookie con JavaScript e inviare le informazioni con un'Autorizzazione-Intestazione.
• Archiviazione locale . Questo è spesso l'unico metodo possibile, se i cookie non sono disponibili. Richiede la gestione con JavaScript.

Che cosa significano le persone quando dicono ...

• "Autenticazione basata su cookie" . Trovo che questo di solito significa "ID sessione, invia per cookie, possibile come testo normale".
• "Autenticazione basata su token" . Di solito questo significa "Reclami, invia utilizzando l'intestazione di autenticazione, codificata come token Json Web."
• "Autenticazione basata sulle attestazioni" . Potrebbe essere qualsiasi cosa tranne un ID di sessione.

In poche parole,

1. Autenticazione basata su cookie

   • Web-client (es .: browser web) memorizza i cookie inviati dal server Web dopo l'autenticazione avvenuta con successo.
   • Cookie contiene informazioni su utente, client, timestamp authN e altri dati utili con id univoco per determinare il cookie.
   • In genere, il cookie viene crittografato dal server Web con l'attributo di dominio impostato (ad esempio google.com ) e inviato al client Web.
   • Ogni volta che il web-client vuole accedere alla risorsa del dominio (es .: mail.google.com ), invierà tutti i cookie in base al suo dominio (es .: google.com ) al web-server, che convalida / verifica e concede / nega l'accesso in base allo stato e al timestamp del cookie.

2. Autenticazione basata sulla sessione

   • Insieme al cookie del client Web, se un server Web memorizza i dati authN dell'utente nel loro back-end, verrà chiamato Autenticazione basata sulla sessione.
   • Questo è molto utile in caso di qualsiasi violazione che il web-client abbia ottenuto l'accesso al sistema dove non dovrebbe accedere, quindi dal back-end, la sessione del client web può essere revocata dall'amministratore.

3. Autenticazione basata su token

   • Generalmente viene utilizzato in scenari non client Web, in cui non è possibile memorizzare cookie nel lato client.
   • Quindi, il server Web invia il token firmato (contiene informazioni su utente, client, timestamp authN e altri dati utili con ID univoco) al client dopo l'autenticazione riuscita.
   • Ogni volta che un cliente desidera accedere a una risorsa, è necessario inviare questo token e il server Web convalida / verifica il token prima di consentire l'accesso alla risorsa.

4. Autenticazione basata sulle attestazioni

   • È uguale all'autenticazione basata su token, solo che aggiunge alcuni ulteriori dati nel token sul client e / o l'utente associato al client.
   • Questi dati riguardano l'autorizzazione, che parla di ciò che il cliente deve fare all'interno della risorsa (ad esempio: mail.read, mail.delete, calendar.read).