Ho letto delle autenticazioni e mi confondo sulla classificazione dei tipi.

Partiamo dall'autenticazione basata su cookie, se ho capito bene, il punto chiave è che tutti i dati, necessari per l'autenticazione dell'utente, sono memorizzati nei cookie. E questa è la mia prima confusione: nei cookie possiamo memorizzare

• ID sessione e quindi diventa un'autenticazione basata su sessione?
• reclami, e quindi dovrebbe essere chiamato come autenticazione basata sui reclami?
• Ho scoperto che alcune persone memorizzano persino il token JWT nei cookie, ma questa sembra un'implementazione personalizzata del proprio flusso di autorizzazioni ...

Passiamo ora all'autenticazione basata su attestazioni. L'elemento principale è l'affermazione e la raccolta di attestazioni potrebbe essere utilizzata come contenitore

• cookie (come discusso sopra)
• token (JWT come esempio).

Dall'altro lato, quando stiamo parlando del token, può contenere qualsiasi tipo di informazione ... ID sessione, ad esempio ...

Quindi cosa mi sono perso? Perché le persone non definiscono qualcosa di simile Cookie-Session-basedo Token-Claims-basedautenticazioni quando parlano di tipi di autenticazione?

Concordo sul fatto 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 sessione . Ciò significa che il server ha un archivio di sessioni che contiene le sessioni attive. Le sessioni sono stateful sul lato server.
• Una serie di affermazioni . I reclami contengono informazioni sulle operazioni che il cliente può eseguire. Il server non tiene traccia di ciascun client autenticato, ma si fida dei reclami. I reclami sono in genere apolidi sul lato server.

In che modo il client invia le informazioni di autenticazione?

• Cookies . I browser inviano automaticamente i cookie con ogni richiesta, dopo che il cookie è stato impostato. I cookie sono vulnerabili a XSRF.
• Altre intestazioni . In genere, l'intestazione di autorizzazione viene utilizzata per questo. 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 semplice, senza segno . Questo può essere usato per gli ID di sessione. Un ID di sessione non è generalmente indovinabile dal client, quindi il server può fidarsi che il client non lo abbia forgiato.
• Json Web Token . I JWT sono firmati crittograficamente e contengono informazioni sulla scadenza. Il client può in genere 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 modificare i dati.

Bonus: in che modo il cliente memorizza le informazioni localmente

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

Cosa significano le persone quando dicono ...

• "Autenticazione basata su cookie" . Trovo che questo di solito significhi "ID sessione, invia tramite cookie, possibile come testo normale".
• "Autenticazione basata su token" . Di solito questo significa "Reclami, invia utilizzando l'intestazione di autenticazione, codificata come token Web Json".
• "Autenticazione basata sui reclami" . Potrebbe essere tutt'altro che un ID di sessione.

In poche parole,

1. Autenticazione basata su cookie

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

2. Autenticazione basata su sessione

   • Insieme al cookie client Web, se un server Web memorizza i dati di autenticazione dell'utente nel loro back-end, verrà chiamato autenticazione basata sulla sessione.
   • Ciò è molto utile in caso di violazione che il client Web ha ottenuto l'accesso al sistema in cui non dovrebbe ottenere l'accesso, 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 Web-client, in cui non è possibile archiviare cookie sul lato client.
   • Quindi, il web server 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 client desidera accedere a una risorsa, deve inviare questo token e il server Web convalida / verifica il token prima di consentire l'accesso alla risorsa.

4. Autenticazione basata sui reclami

   • Ciò equivale all'autenticazione basata su token, solo che aggiunge altri dati nel token sul client e / o sull'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).