Claim e token ID di OpenID Connect

OpenID Connect (OIDC) aggiunge un livello di identità sopra OAuth 2.0. Mentre OAuth 2.0 gestisce l'autorizzazione (a quali risorse può accedere questa app?), OIDC risponde alla domanda sull'identità (chi è l'utente?). OIDC si implementa aggiungendo lo scope "openid" a una richiesta OAuth 2.0; ciò fa sì che il server di autorizzazione restituisca un ID token insieme all'access token.

L'ID token OIDC è un JSON Web Token (JWT) contenente claim sull'utente autenticato. Il JWT è firmato dal server di autorizzazione usando la propria chiave privata (in genere RS256 o ES256), mentre la relying party (l'applicazione client) verifica la firma usando le chiavi pubbliche del server di autorizzazione pubblicate tramite l'endpoint JWKS.

Claim obbligatorie e di uso comune nell'ID token: "sub" (subject, identificatore univoco dell'utente), "iss" (issuer, URL del server di autorizzazione), "aud" (audience, ID del client), "exp" (timestamp Unix di scadenza), "iat" (timestamp Unix di emissione). Facoltative: "auth_time" (momento in cui è avvenuta l'autenticazione), "nonce" (prevenzione del replay), "at_hash" (hash dell'access token), "acr" (classe del contesto di autenticazione), "amr" (metodi di autenticazione utilizzati).

L'endpoint UserInfo di OIDC restituisce claim aggiuntive sull'utente autenticato quando viene chiamato con un access token valido. I client richiedono set di claim specifici tramite gli scope: "profile" (name, picture, locale), "email" (email, email_verified), "address" (formatted address), "phone" (phone_number, phone_number_verified). La risposta UserInfo è un oggetto JSON o un JWT.

La validazione dell'ID token inizia dalla verifica della firma. Il client recupera il JWKS (JSON Web Key Set) del server di autorizzazione dall'endpoint well-known, individua la chiave che corrisponde al parametro "kid" (key ID) dell'header JWT e verifica la firma JWT. Ciò dimostra che il token è stato emesso dal server di autorizzazione legittimo e non è stato manomesso.

Dopo aver verificato la firma, il client deve verificare quanto segue: "iss" deve corrispondere esattamente all'URL previsto del server di autorizzazione, inclusi schema e percorso. "aud" deve contenere il client_id del client. "exp" deve essere nel futuro, quindi i token scaduti devono essere rifiutati. "iat" dovrebbe essere ragionevolmente recente. Tutti e quattro i controlli sono obbligatori secondo la specifica OIDC.

La claim nonce previene gli attacchi di replay degli ID token. Il client genera un nonce casuale e lo include nella richiesta di autorizzazione. Il server di autorizzazione inserisce il nonce nell'ID token. Il client verifica che il nonce nell'ID token corrisponda a quello inviato. Ciò impedisce a un attaccante che abbia catturato un ID token di riutilizzarlo per autenticarsi in una sessione diversa.

Quando OIDC usa il flusso implicito (response_type=id_token), l'ID token viene restituito direttamente nel frammento dell'URL. Il client deve validare at_hash (l'hash dell'access token) per associare l'access token all'ID token. Senza la validazione di at_hash, sono possibili attacchi di sostituzione dell'access token. Questo è un ulteriore motivo per cui il flusso implicito è deprecato.

OIDC definisce associazioni standard tra scope e claim. Lo scope "openid" è obbligatorio e restituisce la claim "sub". "profile" restituisce name, given_name, family_name, nickname, picture, website, locale, zoneinfo, updated_at. "email" restituisce email e email_verified. Richiedere scope non necessari viola il principio della divulgazione minima e può esporre dati sensibili dell'utente.

Quando si implementa un accesso OIDC con più provider (ad esempio, "Sign in with Google" e "Sign in with GitHub"), sono possibili attacchi di iniezione delle claim. Se un attaccante crea un account sul Provider B con l'indirizzo email di una vittima che usa il Provider A, potrebbe ottenere l'accesso se l'applicazione associa gli account basandosi solo sulla claim email. Associare sempre gli account alla coppia (iss, sub), non solo all'email.

Il flusso ibrido OIDC (response_type=code id_token) restituisce sia un codice di autorizzazione sia un ID token dall'endpoint di autorizzazione. L'ID token consente la verifica immediata dell'identità, mentre il codice viene scambiato con i token tramite il back-channel. Si usa quando il client deve visualizzare immediatamente le informazioni dell'utente prima di completare lo scambio di token tramite back-channel.

Quale combinazione di claim deve validare una relying party in un ID token OIDC?

OIDC aggiunge un ID token JWT firmato ai flussi OAuth 2.0. Verificare la firma (JWKS), iss (corrispondenza esatta), aud (client_id), exp (non scaduto) e nonce (se inviato). L'endpoint UserInfo fornisce claim aggiuntive tramite gli scope. Associare gli account alla coppia (iss, sub), mai solo tramite email, per prevenire l'iniezione di claim. Il flusso implicito è deprecato; per OIDC usare il codice di autorizzazione con PKCE.