Voglio capire cosa significa autenticazione basata su token. Ho cercato su Internet ma non ho trovato nulla di comprensibile.
Risposte:
Penso che sia ben spiegato qui - citando solo le frasi chiave del lungo articolo:
Il concetto generale alla base di un sistema di autenticazione basato su token è semplice. Consenti agli utenti di inserire nome utente e password per ottenere un token che consenta loro di recuperare una risorsa specifica, senza utilizzare nome utente e password. Una volta ottenuto il token, l'utente può offrire il token - che offre l'accesso a una risorsa specifica per un periodo di tempo - al sito remoto.
In altre parole: aggiungi un livello di riferimento indiretto per l'autenticazione - invece di dover eseguire l'autenticazione con nome utente e password per ogni risorsa protetta, l'utente esegue l'autenticazione in quel modo una volta (entro una sessione di durata limitata), in cambio ottiene un token limitato nel tempo e utilizza quel token per un'ulteriore autenticazione durante la sessione.
I vantaggi sono molti: ad esempio, l'utente potrebbe passare il token, una volta ottenuto, a un altro sistema automatizzato di cui sono disposti a fidarsi per un tempo limitato e un insieme limitato di risorse, ma non sarebbe disposto fidarsi del loro nome utente e password (ad esempio, con ogni risorsa a cui è consentito loro di accedere, per sempre o almeno fino a quando non cambiano la password).
Se qualcosa non è ancora chiaro, modifica la tua domanda per chiarire COSA non ti è chiaro al 100% e sono sicuro che possiamo aiutarti ulteriormente.
Da Auth0.com
Autenticazione basata su token, si basa su un token firmato che viene inviato al server su ogni richiesta.
Quali sono i vantaggi dell'utilizzo di un approccio basato su token?
Cross-domain / CORS: i cookie + CORS non funzionano bene su domini diversi. Un approccio basato su token consente di effettuare chiamate AJAX verso qualsiasi server, su qualsiasi dominio, poiché si utilizza un'intestazione HTTP per trasmettere le informazioni dell'utente.
Stateless (aka scalabilità lato server): non è necessario mantenere un archivio di sessioni, il token è un'entità autonoma che trasmette tutte le informazioni dell'utente. Il resto dello stato vive nei cookie o nella memoria locale sul lato client.
CDN: puoi servire tutte le risorse della tua app da un CDN (ad esempio javascript, HTML, immagini, ecc.) E il tuo lato server è solo l'API.
Disaccoppiamento: non sei legato a nessun particolare schema di autenticazione. Il token potrebbe essere generato ovunque, quindi l'API può essere chiamata da qualsiasi luogo con un unico modo di autenticare tali chiamate.
Pronto per i dispositivi mobili: quando inizi a lavorare su una piattaforma nativa (iOS, Android, Windows 8, ecc.) I cookie non sono ideali quando il consumo di un approccio basato su token semplifica molto questo.
CSRF: dal momento che non si fa affidamento sui cookie, non è necessario proteggersi dalle richieste tra siti (ad es. Non sarebbe possibile sibare il proprio sito, generare una richiesta POST e riutilizzare il cookie di autenticazione esistente perché non ce ne saranno ).
Prestazioni: qui non stiamo presentando parametri di riferimento perf perfetti, ma è probabile che un round trip di rete (ad es. Ricerca di una sessione nel database) richieda più tempo rispetto al calcolo di un HMACSHA256 per convalidare un token e analizzarne il contenuto.
A tokenè un dato che Server Xpotrebbe essere stato creato e che contiene dati sufficienti per identificare un determinato utente.
È possibile presentare le informazioni di accesso e chiedere Server Xun token; e quindi potresti presentare il tuo tokene chiedere Server Xdi eseguire alcune azioni specifiche dell'utente.
Tokenvengono creati utilizzando varie combinazioni di varie tecniche dal campo della crittografia, nonché con input dal più ampio campo della ricerca sulla sicurezza. Se decidi di andare a creare il tuo tokensistema, faresti meglio ad essere davvero intelligente.
Un token è un pezzo di dati creato dal server e contiene informazioni per identificare un determinato utente e la validità del token. Il token conterrà le informazioni dell'utente, nonché un codice token speciale che l'utente può passare al server con tutti i metodi che supportano l'autenticazione, anziché passare direttamente un nome utente e una password.
L'autenticazione basata su token è una tecnica di sicurezza che autentica gli utenti che tentano di accedere a un server, una rete o un altro sistema sicuro, utilizzando un token di sicurezza fornito dal server.
Un'autenticazione ha esito positivo se un utente può dimostrare a un server di essere un utente valido passando un token di sicurezza. Il servizio convalida il token di sicurezza ed elabora la richiesta dell'utente.
Dopo che il token è stato convalidato dal servizio, viene utilizzato per stabilire il contesto di sicurezza per il client, in modo che il servizio possa prendere decisioni di autorizzazione o attività di controllo per successive richieste dell'utente.
Basato su token (sicurezza / autenticazione)
significa che per provare che abbiamo accesso dobbiamo prima ricevere il token. In uno scenario di vita reale, il token potrebbe essere una carta di accesso all'edificio, potrebbe essere la chiave della serratura di casa tua. Per poter recuperare una chiave magnetica per il tuo ufficio o la chiave di casa tua, devi prima provare chi sei e in effetti hai accesso a quel token. Potrebbe essere qualcosa di semplice come mostrare a qualcuno il tuo ID o dare loro una password segreta. Quindi immagina di avere bisogno di accedere al mio ufficio. Scendo all'ufficio della sicurezza, mostro loro il mio documento d'identità e mi danno questo gettone, che mi fa entrare nell'edificio. Ora ho accesso illimitato per fare tutto ciò che voglio all'interno dell'edificio, purché abbia il mio token con me.
Qual è il vantaggio della sicurezza basata su token?
Se ripensiamo all'API non sicura, quello che dovevamo fare in quel caso era che dovevamo fornire la nostra password per tutto ciò che volevamo fare.
Immaginareche ogni volta che entriamo in una porta del nostro ufficio, dobbiamo dare la password a tutti coloro che siedono vicino alla porta. Ora sarebbe piuttosto male, perché ciò significa che chiunque nel nostro ufficio potrebbe prendere la nostra password e impersonarci, ed è piuttosto male. Invece, quello che facciamo è recuperare il token, ovviamente insieme alla password, ma lo recuperiamo da una persona. E quindi possiamo usare questo token dove vogliamo all'interno dell'edificio. Naturalmente se perdiamo il token, abbiamo lo stesso problema che se qualcun altro conoscesse la nostra password, ma questo ci porta a cose come come assicurarci che se perdiamo il token, possiamo revocare l'accesso e forse il token non dovrebbe vivere per più di 24 ore, quindi il giorno successivo in cui veniamo in ufficio, dobbiamo mostrare di nuovo il nostro documento d'identità. Tuttavia, c'è solo una persona a cui mostriamo l'ID,
La domanda è vecchia e la tecnologia è avanzata, ecco lo stato attuale:
JSON Web Token (JWT) è uno standard aperto basato su JSON (RFC 7519) per il passaggio di richieste tra le parti nell'ambiente delle applicazioni web. I token sono progettati per essere compatti, sicuri per gli URL e utilizzabili soprattutto nel contesto SSO (browser single sign-on).
È solo l'hash che è associato all'utente nel database o in qualche altro modo. Tale token può essere utilizzato per autenticare e quindi autorizzare un utente ad accedere ai contenuti correlati dell'applicazione. Per recuperare questo token sul lato client è necessario il login. Dopo il primo accesso è necessario salvare il token recuperato non altri dati come sessione, ID sessione perché qui tutto è token per accedere ad altre risorse dell'applicazione.
Il token viene utilizzato per garantire l'autenticità dell'utente.
Al giorno d'oggi l'approccio più preferito per proteggere le risorse dell'API Web è l'autenticazione degli utenti nel server API Web utilizzando il token firmato (che contiene informazioni sufficienti per identificare un determinato utente) che deve essere inviato al server dal client con ciascuno e ogni richiesta. Questo si chiama approccio di autenticazione basata su token.
L'autenticazione basata su token funziona come segue:
Un utente inserisce il nome e la password nel client (client significa browser o dispositivi mobili, ecc.).
Il client invia quindi queste credenziali (ovvero nome utente e password) al server di autorizzazione.
Quindi il server di autorizzazione autentica le credenziali del client (ovvero nome utente e password) e quindi genera e restituisce un token di accesso. Questo token di accesso contiene informazioni sufficienti per identificare un utente e contiene anche il tempo di scadenza del token.
L'applicazione client include quindi il token di accesso nell'intestazione Autorizzazione della richiesta HTTP per accedere alle risorse riservate dal server di risorse fino alla scadenza del token.
Il seguente articolo mostra come implementare l'autenticazione basata su token nell'API WEB passo dopo passo.
https://dotnettutorials.net/lesson/token-based-authentication-web-api/
Quando ti registri per un nuovo sito Web, spesso ti viene inviata un'e-mail per attivare il tuo account. Tale e-mail contiene in genere un collegamento su cui fare clic. Parte di quel collegamento, contiene un token, il server è a conoscenza di questo token e può associarlo al proprio account. Al token di solito è associata una data di scadenza, quindi potresti avere solo un'ora per fare clic sul collegamento e attivare il tuo account. Niente di tutto ciò sarebbe possibile con i cookie o le variabili di sessione, poiché non è noto quale dispositivo o browser il cliente stia utilizzando per controllare le e-mail.