OpenID Connect

Voci di Glossario Sicurezza Informatica
Indice dei contenuti

    OpenID Connect (OIDC) è un protocollo di autenticazione costruito sopra OAuth 2.0. Mentre OAuth 2.0 gestisce l’autorizzazione delegata (chi può fare cosa), OIDC aggiunge uno strato di identità: permette a un’applicazione di verificare l’identità dell’utente e di ottenere informazioni di profilo in modo standardizzato e interoperabile.

    OIDC=OAuth 2.0+ID Token (JWT)+UserInfo Endpoint\text{OIDC} = \text{OAuth 2.0} + \text{ID Token (JWT)} + \text{UserInfo Endpoint}

    È il protocollo alla base di “Accedi con Google”, “Accedi con Apple”, “Accedi con Microsoft” e di tutti i sistemi di SSO (Single Sign-On) federato moderni.

    ID Token

    L’elemento centrale di OIDC è l’ID Token: un JWT firmato dall’Authorization Server che contiene claims verificabili sull’identità dell’utente:

    {
  "iss": "https://accounts.google.com",
  "sub": "110169484474386276334",
  "aud": "client_id_dell_applicazione",
  "exp": 1714857600,
  "iat": 1714854000,
  "email": "utente@esempio.it",
  "email_verified": true,
  "name": "Mario Rossi"
}

    Il campo iss (issuer) identifica l’Identity Provider; sub (subject) è l’identificativo univoco e stabile dell’utente presso l’IdP; aud (audience) è il client per cui il token è emesso; exp e iat sono le date di scadenza e emissione. L’applicazione verifica la firma del JWT con la chiave pubblica dell’IdP (pubblicata via JWKS endpoint) e i claim iss, aud, exp prima di accettare il token.

    Flusso con ID Token

    Il flusso Authorization Code con OIDC aggiunge un scope=openid alla richiesta OAuth 2.0. In risposta allo scambio del code, l’Authorization Server restituisce sia l’access_token (per le API) sia l’id_token (per l’identità). Il campo nonce incluso nella richiesta iniziale e verificato nell’ID Token previene i replay attack.

    Confronto con SAML

    SAML 2.0 è il protocollo SSO dominante negli ambienti enterprise legacy; OIDC è il protocollo moderno, basato su JSON e JWT invece di XML, nativo per applicazioni mobile e SPA. Entrambi supportano lo stesso use case (SSO federato con Identity Provider), ma OIDC è più leggero, più facile da implementare correttamente e più adatto all’ecosistema API-first moderno.

    Sicurezza

    Le vulnerabilità più comuni nelle implementazioni OIDC includono la mancata verifica della firma dell’ID Token (accettare il token senza verificarlo contro la chiave pubblica dell’IdP), la mancata verifica dell’aud (accettare token destinati ad altri client), e la mancata verifica del nonce (apertura a replay attack). Le librerie certificate di implementazione — non implementazioni personalizzate — sono la scelta corretta.

    Ultimo aggiornamento: