Questo post del blog mira a fare luce sul rapporto tra gli indicatori di risorse OIDC e il loro ruolo nell'ottenimento dei token di accesso.
In una sessione precedente, abbiamo fornito un'introduzione al protocollo OpenID Connect (OIDC), ai token di aggiornamento, ai token di accesso e ai token ID, componenti essenziali per la costruzione di un'autenticazione robusta nella tua applicazione. Tuttavia, permangono ancora delle domande nella nostra comunità, con una richiesta ricorrente: "Perché il mio token di accesso non è un JWT?”
Per coloro che sono nuovi ai concetti, o anche per coloro che hanno bisogno di un ripasso, questo post del blog mira a fare luce sul rapporto tra gli indicatori di risorse OIDC e il loro ruolo nell'ottenimento dei token di accesso.
Se sei familiare con il protocollo OAuth 2.0, il termine “risorsa” dovrebbe suonare una campana. Poiché l'OIDC si basa su OAuth 2.0, eredita questo stesso concetto.
Una "risorsa" o "risorsa protetta" è una rappresentazione di un'entità che l'applicazione client desidera accedere per conto dell'utente autenticato. Questo potrebbe essere informazioni sull'utente, API del server, o qualsiasi altro dato autorizzato dal tuo server.
Secondo il protocollo, la risorsa è un parametro nelle richieste al server di autorizzazione. È un valore rappresentato come URI assoluta, come https://my-company.com/api. Funziona come un identificatore per la risorsa, corrispondendo potenzialmente a una posizione indicizzabile in rete o anche a un URI unico ma fittizio.
In Logto, è possibile creare una “risorsa API” attraverso la pagina “Console amministrativa → risorse API”. Puoi fare riferimento a questa documentazione per ulteriori dettagli.
Il token di accesso in formato JWT (JSON web token) viene emesso solo quando il parametro "risorsa" è specificato durante la richiesta del token di accesso, e contiene un insieme di rivendicazioni, che puoi decodificare e convalidare, ad esempio, per garantire l'integrità del token e i permessi dell'utente.
Questa "risorsa" diventa quindi una delle rivendicazioni del token aud nel JWT, indicando il pubblico destinatario del token. Vedi RFC-7519.
Quindi, il rapporto diventa chiaro:
aud.aud e altre rivendicazioni relative ai permessi per garantire la sicurezza della richiesta API.🤔 Ma cosa succede se il cliente non specifica la risorsa quando richiede il token di accesso?
Nel caso di Logto, se l'indicatore di risorsa non è specificato quando si richiede il token di accesso, il server di autorizzazione presume che sia per l'endpoint OIDC /userinfo, e quindi viene emesso un token di accesso opaco che può essere utilizzato successivamente dal client per richiedere il profilo utente, come ID utente, nome, email, ecc., dall'endpoint userinfo OIDC.
In qualsiasi SDK Logto, è possibile ottenere tale token se si chiama getAccessToken() o si richiede direttamente l'endpoint del token OIDC senza specificare il parametro resource.
Si noti che questo token di accesso opaco non è adatto per le tue richieste di risorse API, poiché non c'è modo di verificarlo senza richiedere il server OIDC.
Le risorse OIDC definiscono dati o servizi specifici che un'applicazione client desidera accedere per conto dell'utente, con i token di accesso JWT che servono come mezzo sicuro per tale accesso. La rivendicazione "aud" nei token di accesso JWT si allinea con l'indicatore di risorsa, aiutando i server a verificare i permessi su richieste del client.
In Logto, il token di accesso opaco è esclusivamente per il recupero delle informazioni del profilo utente dall'endpoint userinfo OIDC, mentre i clienti possono richiedere più token di accesso, ciascuno dedicato a una risorsa specifica.
Speriamo che questo post del blog chiarisca eventuali dubbi e colleghi i punti per voi. Sentitevi liberi di farci sapere i vostri pensieri.