OpenID Connect (OIDC)

OpenID Connect è un sottile livello di identità costruito sopra OAuth 2.0. OAuth risponde alla domanda che cosa può fare questa app; OIDC risponde alla domanda chi è l'utente.

• Standardizza il modo in cui i client autenticano gli utenti e ricevono claim di identità verificati.
• Introduce l'ID token come asserzione di autenticazione firmata crittograficamente.

Prima di OIDC, gli sviluppatori usavano impropriamente i token di accesso OAuth per il login, causando vulnerabilità di tipo confused deputy e di impersonificazione.

L'artefatto distintivo di OIDC è l'ID token, un JWT firmato che descrive l'evento di autenticazione.

• Contiene claim relativi a chi ha effettuato l'accesso e quando.
• È destinato al client, non al resource server.

Non inviare mai un ID token a un'API come credenziale di accesso e non accettarne mai uno senza convalidarne la firma e i claim.

Convalidare un ID token significa verificare claim specifici, non solo la firma.

• iss L'issuer deve corrispondere all'IdP previsto.
• aud L'audience deve contenere il vostro client_id.
• exp / iat Il token non deve essere scaduto e deve essere stato emesso di recente.
• sub Identificatore stabile e univoco dell'utente.
• nonce Deve corrispondere al valore inviato dal client.

OIDC riutilizza il flusso Authorization Code, ma aggiunge lo scope openid e un nonce.

• Il client richiede lo scope openid (oltre agli scope facoltativi profile e email).
• Il token endpoint restituisce un ID token insieme al token di accesso.
• Il nonce collega l'ID token alla richiesta originale, impedendone il replay.

I provider OIDC pubblicano le proprie chiavi di firma in un endpoint JWKS, individuabile tramite il documento di configurazione well-known.

• Recuperare le chiavi da jwks_uri e associare l'header kid del token.
• Verificare usando l'algoritmo asimmetrico indicato (RS256, ES256).

Rifiutare l'algoritmo none e non fidarsi mai di un valore dell'algoritmo fornito esclusivamente dal token.

Il nonce sta agli ID token come state sta al reindirizzamento: un valore monouso che associa la risposta alla richiesta.

• Il client genera un nonce casuale e lo memorizza nella sessione.
• L'IdP lo ripete all'interno dell'ID token.
• Alla ricezione, il client verifica che il nonce corrisponda e non sia già stato usato.

Questo impedisce il replay del token e l'iniezione di un token emesso per una sessione diversa.

Per ottenere ulteriori dati del profilo oltre a quelli presenti nell'ID token, OIDC definisce l'endpoint UserInfo.

• Il client lo chiama con il token di accesso (non con l'ID token).
• Restituisce claim come nome, email e immagine per il soggetto autenticato.

Confrontare sempre il sub restituito con il sub dell'ID token per impedire la sostituzione dei claim.

OIDC standardizza il discovery, così i client possono configurare automaticamente gli endpoint e le funzionalità supportate.

• Il documento /.well-known/openid-configuration elenca gli endpoint, gli scope supportati e gli algoritmi.
• Eseguire il pinning dell'issuer o convalidarlo; non seguire ciecamente il discovery proveniente da un host controllato da un attaccante.

Il discovery semplifica l'integrazione, ma l'issuer rimane un'ancora di fiducia che è necessario verificare.

La terminazione della sessione tra app federate è gestita dalle specifiche di logout OIDC.

• Il logout front-channel usa reindirizzamenti o iframe del browser per cancellare la sessione di ogni relying party.
• Il logout back-channel invia token di logout tra server, è più affidabile ma richiede endpoint dedicati.

Senza un logout coordinato, un utente può disconnettersi da un'app rimanendo connesso alle altre: un autentico rischio per la gestione delle sessioni.

I problemi di identità spesso derivano dal saltare i passaggi di convalida.

• Accettare token senza verificare aud (token destinato a un altro client).
• Ignorare iss, consentendo lo spoofing dell'IdP.
• Non convalidare la firma o accettare alg: none.
• Confondere gli ID token con i token di accesso.
• Omettere i controlli sul nonce, consentendo il replay.

Se l'obiettivo è il login, usare OIDC, non OAuth puro.

• I token di accesso OAuth sono opachi al client e non dimostrano nulla sull'identità.
• Un token di accesso può essere valido per un utente o un'app diversa, causando impersonificazione se usato per il login.
• Gli ID token OIDC sono esplicitamente asserzioni di identità vincolate all'audience.

Questa distinzione previene la classica vulnerabilità di autenticazione del confused deputy.

Punti chiave:

• OIDC aggiunge un livello di identità a OAuth 2.0; l'ID token è un JWT firmato che dimostra l'autenticazione.
• Convalidare sempre iss, aud, exp, signature (via JWKS) e nonce.
• Gli ID token sono destinati al client; i token di accesso alle API; non scambiarne mai i ruoli.
• Usare nonce contro il replay e state contro il CSRF.
• Usare OIDC, non OAuth puro, quando è necessario autenticare gli utenti.