oauth 2.0oidc

Cos'è Token opaco?

Un token opaco è una stringa casuale e unica che è priva di significato per il client ma serve come chiave di riferimento per cercare i dati di autorizzazione nel database del server.

Che cos’è un token opaco?

Un token opaco è una stringa casuale e unica che è priva di significato per il client ma serve come chiave di riferimento per cercare i dati di autorizzazione nel database del server.

I token opachi sono solitamente generati utilizzando un Generatore di numeri pseudocasuali crittograficamente sicuro per garantire la sua imprevedibilità e sicurezza, e il suo formato è determinato dal suo issuer (issuer).

Ecco un esempio di un token opaco:

M-oxIny1RfaFbmjMX54L8Pl-KQEPeQvF6awzjWFA3iq

Qual è la differenza tra JWT (JSON Web Token) e token opaco?

La principale differenza risiede nel modo in cui questi token gestiscono e convalidano le informazioni di autorizzazione:

Un token opaco è una stringa casuale che non contiene informazioni di per sé. Il server deve interrogare il suo database backend per recuperare qualsiasi dato di autorizzazione associato a questo token. Questo rende i token opachi completamente dipendenti dall’authorization server (authorization server) per la convalida e l’interpretazione.

JWT è un token autonomo che trasporta tutte le informazioni necessarie al suo interno.

Ecco un esempio di un JWT, è una stringa codificata in base64:

eyJhbGciOiJIUzI1NiIs.eyJzdWIiOiIxMjM0NTY3O.SflKxwRJSMeKKF2QT4f

E contiene tre parti separate da punti:

Header - Contiene informazioni sul tipo di token e l’algoritmo utilizzato per la firma. Ad esempio, {"alg": "HS256", "typ": "JWT"}.
Payload - Contiene claim (claim)—informazioni sull’utente o sull’autorizzazione, come ID utente, tempo di scadenza e scope (scope). Chiunque può decodificarlo per vedere i claim perché è codificato ma non crittografato.
Signature - Generata combinando l’header, il payload e una chiave segreta utilizzando l’algoritmo specificato. Questa firma viene utilizzata per verificare l’integrità del token e garantire che non sia stato manomesso.

Questa struttura consente ai JWT di essere convalidati e utilizzati senza interrogare un database.

Per ulteriori informazioni dettagliate sui JWT, si prega di fare riferimento a JSON Web Token (JWT) .

E dai un’occhiata a Token opaco vs JWT per saperne di più sulle loro differenze in modo più approfondito.

Come convalidare un token opaco

Nei sistemi semplici, la convalida del token opaco è tipicamente gestita direttamente dal server, che interroga il database utilizzando il token opaco come chiave per recuperare le informazioni di autorizzazione associate.

Nei sistemi multi-parte che introducono OAuth 2.0, più resource server (resource server) (vedi: Server delle risorse ) potrebbero dover convalidare lo stesso token opaco. OAuth 2.0 fornisce un meccanismo standardizzato di token introspection per questa convalida:

Per informazioni dettagliate sulla token introspection, si prega di fare riferimento a Introspezione del token (Token introspection) .

Come vengono utilizzati i token opachi in OIDC?

Nel contesto di OIDC ( OpenID Connect (OIDC) ), i token opachi servono a scopi specifici in diversi scenari:

Recupero del profilo utente

Per impostazione predefinita, quando un client richiede un access token senza specificare una risorsa e include lo scope openid, l’authorization server emette un access token opaco. Questo token è utilizzato principalmente per recuperare informazioni sul profilo utente dall’endpoint /oidc/userinfo di OIDC (vedi: Endpoint userinfo ).

Scambio del refresh token

I refresh token (refresh token) (vedi: Token di aggiornamento (Refresh token) ) sono tipicamente emessi come token opachi poiché vengono scambiati solo tra il client e l’authorization server. Quando l’attuale access token scade, il client può utilizzare il refresh token opaco per ottenere un nuovo access token senza ri-autenticare l’utente.

Quali sono i pro e i contro del token opaco?

Pro

Sicurezza: I token opachi sono perfetti per gestire dati sensibili come i refresh token. Poiché il contenuto è completamente casuale e privo di significato, anche se qualcuno intercetta il token, non può estrarre alcuna informazione utile. Questo li rende particolarmente preziosi in scenari ad alta sicurezza come le transazioni bancarie o la gestione di dati sensibili degli utenti.
Revocabilità: Il server può invalidare immediatamente un token opaco in qualsiasi momento. Questo è particolarmente utile quando è necessario rimuovere rapidamente l’accesso dell’utente. A differenza dei JWT che rimangono validi fino alla loro scadenza, i token opachi possono essere revocati istantaneamente (vedi: Limitazioni dei JWT ).
Dimensione: I token opachi sono tipicamente molto più brevi dei JWT. Questa dimensione ridotta riduce l’uso della larghezza di banda di rete e i requisiti di archiviazione. Il vantaggio diventa particolarmente evidente nei sistemi che trasmettono frequentemente token, come le applicazioni mobili o i dispositivi IoT.
Semplicità: L’implementazione dei token opachi è semplice. Si genera una stringa casuale e la si memorizza con i dati associati. Non c’è bisogno di gestire complessi processi di crittografia o verifica delle firme come con i JWT. Questa semplicità li rende ideali per l’autenticazione dei sistemi interni.

Contro

Stateful: Ogni token opaco richiede archiviazione sul lato server. Questo crea ulteriore complessità nei sistemi distribuiti perché i dati del token devono essere sincronizzati tra più server. Ad esempio, se hai più server di autenticazione, tutti devono avere accesso allo stesso database di token o sistema di cache per convalidare correttamente i token.
Prestazioni: La convalida del token richiede sempre una ricerca nel database o una chiamata API. Nei sistemi ad alto traffico, queste query aggiuntive al database possono creare colli di bottiglia nelle prestazioni. Ad esempio, se il tuo sistema gestisce migliaia di richieste al secondo, ciascuna richiedendo la convalida del token, il carico aggiuntivo sul database diventa significativo.
Interoperabilità: Sistemi diversi potrebbero implementare i token opachi in modi diversi. Questo può causare sfide di integrazione quando si lavora con servizi di terze parti o diversi authorization server. Sebbene standard come la token introspection di OAuth 2.0 aiutino, potresti comunque incontrare problemi di compatibilità quando i sistemi utilizzano formati di token o metodi di convalida diversi.