Che cos'è esattamente il token bearer OAuth 2.0?


171

Secondo RFC6750 -Il framework di autorizzazione OAuth 2.0: utilizzo di token al portatore, il token al portatore è:

Un token di sicurezza con la proprietà che qualsiasi parte in possesso del token (un "portatore") può utilizzare il token in qualsiasi modo possibile qualsiasi altra parte in possesso di esso.

Per me questa definizione è vaga e non riesco a trovare alcuna specifica.

  • Supponiamo che io stia implementando un fornitore di autorizzazione, posso fornire qualsiasi tipo di stringa per il token al portatore?
  • Può essere una stringa casuale?
  • Deve essere una codifica base64 di alcuni attributi?
    Dovrebbe essere hash?
  • E il fornitore di servizi deve interrogare il fornitore di autorizzazione per convalidare questo token?

Grazie per qualsiasi puntatore.


Supponiamo che io stia implementando un fornitore di autorizzazione, posso fornire qualsiasi tipo di stringa per il token al portatore? Può essere una stringa casuale ?. I token di accesso vengono emessi tramite gli endpoint OAuth 2.0 di Auth0: / authorize e / oauth / token. È possibile utilizzare qualsiasi libreria compatibile con OAuth 2.0 per ottenere i token di accesso. Se non si dispone già di una libreria OAuth 2.0 preferita, Auth0 fornisce librerie per molte lingue e framework.
Bharathkumar V

Risposte:


146

Token portatore
Un token di sicurezza con la proprietà che qualsiasi parte in possesso del token (un "portatore") può utilizzare il token in qualsiasi modo possibile con qualsiasi altra parte in possesso di esso. L'uso di un token al portatore non richiede al portatore di dimostrare il possesso di materiale chiave crittografico (prova di possesso).

Il token bearer è stato creato per te dal server di autenticazione. Quando un utente autentica l'applicazione (client), il server di autenticazione si avvia e genera per te un token. I token al portatore sono il tipo predominante di token di accesso utilizzato con OAuth 2.0. Un token Bearer in pratica dice "Concedi l'accesso a questo token".

Il token Bearer è normalmente una sorta di valore opaco creato dal server di autenticazione. Non è casuale; viene creato in base all'utente che ti dà accesso e al client a cui l'applicazione accede.

Per accedere ad un'API, ad esempio, è necessario utilizzare un token di accesso. I token di accesso sono di breve durata (circa un'ora). Si utilizza il token di connessione per ottenere un nuovo token di accesso. Per ottenere un token di accesso, si invia al server di autenticazione questo token di connessione insieme all'ID client. In questo modo il server sa che l'applicazione che utilizza il token bearer è la stessa applicazione per cui è stato creato il token bearer. Esempio: non posso semplicemente prendere un token al portatore creato per la tua applicazione e usarlo con la mia applicazione non funzionerà perché non è stato generato per me.

Il token di Google Refresh è simile al seguente: 1 / mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM

copiato dal commento: non credo ci siano restrizioni sui token al portatore che fornisci. L'unica cosa che mi viene in mente è che è bello permetterne più di uno. Ad esempio, un utente può autenticare l'applicazione fino a 30 volte e i vecchi token al portatore continueranno a funzionare. oh e se uno non fosse stato usato per dire 6 mesi lo rimuoverei dal tuo sistema. È il tuo server di autenticazione che dovrà generarli e convalidarli, quindi dipende da come è formattato.

Aggiornare:

Un token bearer è impostato nell'intestazione Autorizzazione di ogni richiesta HTTP di azione in linea. Per esempio:

POST /rsvp?eventId=123 HTTP/1.1
Host: events-organizer.com
Authorization: Bearer AbCdEf123456
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko; Gmail Actions)

rsvpStatus=YES

La stringa "AbCdEf123456"nell'esempio sopra è il token di autorizzazione al portatore. Questo è un token crittografico prodotto dal server di autenticazione. Tutti i token al portatore inviati con azioni hanno il campo problema, con il campo destinatario che specifica il dominio del mittente come URL del modulo https: //. Ad esempio, se l'e-mail proviene da noreply@example.com, il pubblico è https://example.com .

Se si utilizzano token di connessione, verificare che la richiesta provenga dal server di autenticazione e sia destinata al dominio del mittente. Se il token non viene verificato, il servizio deve rispondere alla richiesta con un codice di risposta HTTP 401 (non autorizzato).

I token bearer fanno parte dello standard OAuth V2 e sono ampiamente adottati da molte API.


2
@ Xavier Il token Egea Bearer è sostanzialmente il token di aggiornamento e non il token di accesso.
Akhil Nambiar,

13
Token portatore non significa che è un token di aggiornamento @AqeelSmith tools.ietf.org/html/rfc6750#section-6.1.1
Suman Kundu

9
Il primo paragrafo implica che un token Bearer è un token di aggiornamento e non un token di accesso. Questo non è il caso. Dalla specifica del token Bearer "Questa specifica descrive come effettuare richieste di risorse protette quando il token di accesso OAuth è un token bearer." RFC6750
Daniel,

8
Dopo aver letto la risposta, ho anche pensato che i token Bearer e i token di aggiornamento fossero gli stessi. La risposta dovrebbe essere aggiornata per chiarire questo.
KurioZ7,

2
Questa risposta è molto fuorviante. I token al portatore NON sono token di aggiornamento, come afferma la dichiarazione iniziale di questa risposta. Per favore Correggi.
think01,

67

Mentre leggevo la tua domanda, ho provato senza successo a cercare su Internet come i token Bearer sono crittografati o firmati. Immagino che i token al portatore non siano sottoposti a hash (forse parzialmente, ma non completamente) perché in tal caso, non sarà possibile decrittografarlo e recuperare le proprietà degli utenti da esso.

Ma la tua domanda sembra cercare di trovare risposte sulla funzionalità del token Bearer:

Supponiamo che io stia implementando un fornitore di autorizzazione, posso fornire qualsiasi tipo di stringa per il token al portatore? Può essere una stringa casuale? Deve essere una codifica base64 di alcuni attributi? Dovrebbe essere hash?

Quindi, proverò a spiegare come funzionano i token Bearer e i token di aggiornamento:

Quando l'utente richiede al server un token che invia l'utente e la password tramite SSL, il server restituisce due elementi: un token di accesso e un token di aggiornamento .

Un token di accesso è un token Bearer che dovrai aggiungere in tutte le intestazioni di richiesta per essere autenticato come utente concreto.

Authorization: Bearer <access_token>

Un token di accesso è una stringa crittografata con tutte le proprietà dell'utente, i reclami e i ruoli desiderati. (È possibile verificare che la dimensione di un token aumenti se si aggiungono più ruoli o attestazioni). Una volta che il server delle risorse riceve un token di accesso, sarà in grado di decrittografarlo e leggere queste proprietà dell'utente. In questo modo, l'utente verrà convalidato e concesso insieme a tutta l'applicazione.

I token di accesso hanno una scadenza breve (ovvero 30 minuti). Se i token di accesso fossero scaduti, sarebbe un problema, poiché teoricamente non è possibile revocarli. Quindi immagina un utente con un ruolo = "Admin" che cambia in "Utente". Se un utente mantiene il vecchio token con role = "Admin", sarà in grado di accedere fino alla scadenza del token con diritti di amministratore. Ecco perché i token di accesso hanno una scadenza breve.

Ma viene in mente un problema. Se un token di accesso ha una scadenza breve, dobbiamo inviare ogni breve periodo l'utente e la password. È sicuro? No, non lo è. Dovremmo evitarlo. Questo è quando i token di aggiornamento sembrano risolvere questo problema.

I token di aggiornamento sono memorizzati nel DB e avranno una scadenza lunga (esempio: 1 mese).

Un utente può ottenere un nuovo token di accesso (quando scade, ad esempio ogni 30 minuti) utilizzando un token di aggiornamento, che l'utente ha ricevuto nella prima richiesta di un token. Alla scadenza di un token di accesso, il client deve inviare un token di aggiornamento. Se questo token di aggiornamento esiste nel DB, il server restituirà al client un nuovo token di accesso e un altro token di aggiornamento (e sostituirà il vecchio token di aggiornamento con quello nuovo).

Nel caso in cui un token di accesso utente sia stato compromesso, il token di aggiornamento di tale utente deve essere eliminato dal DB. In questo modo il token sarà valido solo fino alla scadenza del token di accesso perché quando l'hacker tenta di ottenere un nuovo token di accesso inviando il token di aggiornamento, questa azione verrà negata.


2
Non capisco questa parte: "Una volta che il server di autorizzazione riceve un token di accesso, sarà in grado di decrittografarlo e leggere queste proprietà dell'utente. In questo modo, l'utente verrà convalidato e concesso insieme a tutta l'applicazione". Il server di autorizzazione non è quello che garantisce il token di accesso, non lo riceve? Sto cercando di approfondire questo argomento e molti esempi chiariscono chiaramente tra il server di autorizzazione e il server di risorse. Quello che ho capito è che ottieni il token di accesso dal server di autorizzazione e lo inoltri con ogni richiesta che fai al server delle risorse?
Kivikall,

1
@kivikall Hai ragione. L'ho cambiato nella risposta. Il server di risorse riceve il token (il token che il server di autorizzazione ha crittografato nel processo di creazione del token) in ogni richiesta e lo decodifica.
Xavier Egea,

1
@kivikall In realtà, per decrittografare un token dovrebbe essere qualcosa correlato all'autorizzazione, quindi dovrebbe appartenere al server di autorizzazione. Ecco perché l'ho scritto nella risposta. In pratica, ciò significherebbe che in ogni richiesta è necessario convalidare con il server di autorizzazione il token ricevuto (magari eseguendo un'altra richiesta). Pertanto, per evitare la perdita di prestazioni, è meglio fornire alcune funzionalità per decrittografare il token sul server delle risorse. Controlla il link seguente: stackoverflow.com/questions/12296017/…
Xavier Egea,

Ma su ogni richiesta il Resource Server dovrebbe verificare se l'AccessToken fornito è valido contro il Server di autorizzazione. Quindi, se un ruolo cambia, la modifica può essere riflessa immediatamente dal server di autenticazione, giusto? Inoltre, perché dovremmo eliminare RefreshToken se AccessToken fosse compromesso? RefreshToken non può essere calcolato sulla base di AccessToken, quindi quando scade l'hacker viene nuovamente bloccato.
mandarino,

Come ho detto, il token di accesso contiene informazioni sull'utente, come il ruolo. Se un ruolo utente cambia, questa modifica si rifletterà sul token successivo alla scadenza del token corrente. Ciò significa che in un breve periodo di tempo (fino alla scadenza del token di accesso) l'utente manterrà lo stesso ruolo e il server di autenticazione lo consentirà perché il token è ancora valido. Per quanto riguarda la seconda domanda, l'eliminazione di un token di aggiornamento consente all'utente di inserire nuovamente le proprie credenziali. Questo è ciò che vogliamo se un token di accesso è compromesso. In altri casi, un hacker può essere autorizzato fino alla scadenza del refreshtoken (per ex.1 mese)
Xavier Egea,

9

Il token al portatore è una o più ripetizioni di alfabeto, cifra, "-", "." , "_", "~", "+", "/" seguito da 0 o più "=".

RFC 6750 2.1. Campo intestazione richiesta di autorizzazione (il formato è ABNF (Augmented BNF))

The syntax for Bearer credentials is as follows:

     b64token    = 1*( ALPHA / DIGIT /
                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
     credentials = "Bearer" 1*SP b64token

Sembra Base64 ma secondo il token nell'intestazione deve essere codificato base64? , non è.

Scavando un po 'più a fondo in "HTTP / 1.1, parte 7: Autenticazione" **, tuttavia, vedo che b64token è solo una definizione di sintassi ABNF che consente i caratteri tipicamente utilizzati in base64, base64url, ecc. Quindi il b64token non lo fa definire qualsiasi codifica o decodifica, ma piuttosto definisce semplicemente quali caratteri possono essere utilizzati nella parte dell'intestazione di autorizzazione che conterrà il token di accesso.

Riferimenti


Non stai spiegando affatto lo scopo dei token Bearer.
Jaime Hablutzel,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.