Esplora i campi chiave e le applicazioni pratiche della configurazione di OpenID Connect.
Nel mondo digitale odierno, l'autenticazione è diventata un componente centrale per la sicurezza di siti web e applicazioni. OpenID Connect (OIDC), uno strato di autenticazione costruito sopra il protocollo OAuth 2.0, offre un modo standardizzato e diretto per autenticare le identità.
Tuttavia, integrare correttamente OIDC può essere scoraggiante, specialmente per i principianti. Un buon punto di partenza spesso è il file di configurazione OIDC, solitamente trovato nell'URL {authServerUrl}/.well-known/openid-configuration, che contiene tutti i dettagli necessari per implementare i servizi OIDC.
Questa guida mira a chiarire i campi chiave all'interno di questa configurazione, aiutando gli sviluppatori a comprenderne l'importanza e le applicazioni pratiche per integrare meglio OIDC nei loro progetti.
La configurazione OIDC è un file JSON simile al seguente:
Successivamente, approfondiremo alcuni dei campi chiave.
Quando si integrano i servizi OIDC, il primo passo solitamente implica la gestione delle richieste di login degli utenti nell'applicazione. Questo processo include il reindirizzamento degli utenti all'authorization_endpoint del server di autorizzazione. Questo endpoint è l'indirizzo del server a cui vengono inviate le richieste di autorizzazione, guidando gli utenti alla pagina di accesso per l'autenticazione.
Quando si effettua una richiesta all'authorization_endpoint, essa deve essere configurata con parametri di query aggiuntivi per ogni autorizzazione:
response_type: Specifica il tipo di autorizzazione restituita. Questo tipicamente include "code" (per il flusso di codice di autorizzazione), "token" (per il flusso implicito), e "id_token token" o "code id_token" (per il flusso ibrido), che possono essere trovati nel campo response_types_supported della configurazione OIDC.client_id: Un identificatore unico assegnato all'applicazione dal server di autorizzazione quando l'app viene registrata. Questo ID è utilizzato dal server di autorizzazione per riconoscere l'applicazione client che avvia la richiesta.scope: Definisce l'area di accesso richiesta, specificando le risorse o le informazioni utente accessibili. Gli scope comuni includono "openid" (obbligatorio), "profile", e "email", tra gli altri. È possibile trovare gli scope supportati nel campo scopes_supported della configurazione OIDC; diversi scope dovrebbero essere separati da spazi.redirect_uri: Dopo il login o l'autorizzazione, il server di autorizzazione reindirizza l'utente all'URI fornito dall'applicazione. Questo URI deve corrispondere esattamente all'URI fornito durante la registrazione dell'applicazione.state: Una stringa generata casualmente utilizzata per proteggere il client dagli attacchi cross-site request forgery. La coerenza dello stato tra la richiesta di autorizzazione e il callback deve essere mantenuta per garantire la sicurezza.Questi parametri permettono agli sviluppatori di controllare con precisione il comportamento delle richieste di autorizzazione OIDC, assicurando che siano sicure e soddisfino le esigenze dell'applicazione.
Dopo aver completato la richiesta all'authorization_endpoint e aver superato l'autenticazione, gli utenti vengono reindirizzati all'redirect_uri specificata, che includerà un parametro di query molto cruciale—code. Questo codice di autorizzazione è fornito dal server di autorizzazione ed è il risultato dell'autenticazione dell'utente e dell'autorizzazione dell'applicazione ad accedere alle loro informazioni presso il server di autorizzazione.
token_endpoint è l'endpoint del server utilizzato dal server di autorizzazione per scambiare il suddetto codice di autorizzazione con token di accesso e di aggiornamento. Nel flusso di codice di autorizzazione dell'OAuth 2.0, questo passaggio è cruciale in quanto coinvolge la conversione del codice di autorizzazione ottenuto in token di accesso reali, che l'app può utilizzare per accedere alle risorse protette dell'utente.
Ecco come viene implementato lo scambio del codice di autorizzazione per i token di accesso (nota che in questo esempio viene utilizzato il metodo di autenticazione client_secret_post. Per altri metodi di autenticazione supportati, fare riferimento all'analisi successiva del campo
token_endpoint_auth_methods_supportedIn questo codice, inviamo prima una richiesta all'token_endpoint usando il metodo POST. Il tipo di contenuto è impostato su application/x-www-form-urlencoded, che è richiesto dalla maggior parte dei server di autorizzazione. Il corpo della richiesta include i seguenti parametri:
redirectUri dopo che l'utente ha completato l'autorizzazione."authorization_code" qui, il che indica che il token di accesso viene ottenuto tramite il codice di autorizzazione.Questa funzione viene eseguita in modo asincrono e restituisce un oggetto JSON contenente il token di accesso, che l'applicazione può utilizzare per richiedere dati utente o eseguire altre operazioni.
userinfo_endpoint è l'endpoint del server utilizzato dal server di autorizzazione per ottenere informazioni dettagliate sugli utenti autenticati. Dopo che gli utenti hanno autorizzato con successo e ottenuto token di accesso tramite il token_endpoint, l'applicazione può richiedere questo endpoint per accedere alle informazioni del profilo dell'utente, come il nome utente e l'indirizzo email. Le informazioni specifiche ottenute dipendono dallo scope specificato dall'utente nella richiesta di autenticazione.
In questa funzione, utilizziamo prima il metodo GET per richiedere l'userinfo_endpoint, includendo il campo Authorization nell'intestazione della richiesta composto dal token_type e dall'accessToken. Questa è un'operazione standard secondo la specifica OAuth 2.0, che garantisce il recupero sicuro delle informazioni utente. Inoltre, l'ambito delle informazioni utente accessibili tramite il token di accesso dipende interamente dai valori dei parametri scope adottati dall'utente durante l'avvio dell'autorizzazione. Ad esempio, se viene utilizzato lo scope email, la risposta dovrebbe includere l'indirizzo email dell'utente.
L'issuer identifica l'URL del server di autorizzazione, mentre il jwks_uri fornisce l'URI per il JSON Web Key Set (JWKS), che è un insieme di chiavi pubbliche utilizzate per verificare le firme JWT. Verificare l'issuer e la firma del JWT sono passaggi fondamentali per garantire la sicurezza dei token, ma in scenari reali
il processo di verifica generalmente include anche il controllo della validità del token, del pubblico, dell'ambito di autorizzazione e di altri campi importanti.
Il seguente codice dimostra principalmente come utilizzare l'issuer e il jwks_uri insieme per verificare un JWT:
I campi claims_supported e scopes_supported dichiarano gli attributi utente (claims) e gli ambiti di accesso (scopes) supportati dal server di autorizzazione. Aiutano i client a capire quali attributi utente e ambiti di accesso sono supportati dal server di autorizzazione, permettendo ai client di costruire efficacemente richieste di autorizzazione e analizzare le risposte.
Quando si costruisce una richiesta di autorizzazione, i client possono specificare lo scope richiesto in base alle esigenze dell'applicazione. Scope definisce le risorse e le operazioni a cui il client richiede accesso, come openid, email, profile e altri.
È importante notare che gli specifici claims accessibili in ciascuna richiesta di autorizzazione variano in base ai valori degli scope specificati all'inizio della richiesta di autenticazione. Ad esempio, lo scope email garantisce l'accesso all'indirizzo email dell'utente, mentre lo scope phone fornisce l'accesso al loro numero di telefono. Pertanto, i client dovrebbero scegliere con cura lo scope rilevante per soddisfare le esigenze dell'applicazione quando creano una richiesta di autorizzazione, assicurandosi di poter recuperare gli attributi utente necessari:
Il campo
token_endpoint_auth_methods_supportedQuando si autentica utilizzando l'endpoint del token, i metodi di autenticazione comuni includono client_secret_post, client_secret_basic e client_secret_jwt.
client_secret_post: Il client utilizza il suo identificatore di client e il suo secret per costruire un corpo codificato in form, che viene inviato come parte del corpo della richiesta. Abbiamo già visto un esempio di questo metodo nella sezione token_endpoint sopra.
client_secret_basic: Il client utilizza il suo identificatore di client e il suo secret per costruire un'intestazione di autenticazione di base, che viene aggiunta all'intestazione della richiesta.
client_secret_jwt: Il client utilizza un JWT (JSON Web Token) come asserzione del client per autenticarsi. Questo JWT contiene l'identificatore del client e alcuni metadati aggiuntivi ed è firmato utilizzando il secret del client. Dopo aver ricevuto la richiesta, il server di autorizzazione verifica l'identità del client convalidando la firma del JWT.Nelle applicazioni pratiche, i client devono selezionare il metodo di autenticazione appropriato in base ai metodi supportati dal server di autorizzazione, e assicurarsi che le informazioni di autenticazione siano aggiunte correttamente alla richiesta per scambiare in modo sicuro il codice di autorizzazione con i token di accesso.
Abbiamo ora esplorato i campi chiave nella configurazione OIDC, concentrandoci sui loro scopi e applicazioni. Comprendere questi dettagli migliorerà la tua comprensione di OpenID Connect, permettendoti di integrarlo e utilizzarlo più efficacemente nei tuoi progetti. Armati di questa conoscenza, sarai meglio equipaggiato per sfruttare al massimo il potenziale di OIDC per soluzioni di autenticazione degli utenti più sicure ed efficienti.
Logto è un servizio di autenticazione basato su OIDC, che offre una suite completa di SDK in varie lingue insieme a numerosi tutorial di integrazione, permettendoti di integrare facilmente login OAuth / OIDC nelle tue applicazioni in pochi minuti. Se stai cercando un servizio OIDC affidabile e facile da usare, prova Logto oggi stesso!