OpenID Connect: cos'è, protocollo di autenticazione e autorizzazione

Cos'è OpenID Connect?

OpenID Connect (OIDC) è un protocollo di autenticazione aperto costruito come estensione su OAuth 2.0. Standardizza ciò che mancava a OAuth 2.0: la verifica dell'identità dell'utente. Se OAuth 2.0 risponde alla domanda “quale applicazione ha accesso?”, allora OIDC risponde “chi è esattamente questo utente?”.

Il protocollo utilizza un ID Token — un JSON Web Token (JWT) che contiene un insieme di claim: un identificatore univoco del soggetto, email, nome, avatar, timestamp di emissione e scadenza. L'applicazione client può verificare crittograficamente l'ID Token — il server firma il token con RS256 o ES256, e il client controlla la firma con la chiave pubblica ottenuta tramite l'endpoint JWKS.

Secondo Auth0, 2025, oltre il 78% delle applicazioni mobili che utilizzano autenticazione di terze parti impiegano OIDC tramite Google Sign-In o Sign in with Apple. Questo rende il protocollo lo standard de facto per il login sociale e l'autenticazione aziendale.

Come funziona OpenID Connect

OpenID Connect definisce diversi flussi (flows) a seconda del tipo di client. Per le applicazioni mobili, lo standard è l'Authorization Code Flow con Proof Key for Code Exchange (PKCE) — offre sicurezza anche senza un client secret sul dispositivo.

Identity Provider e il suo ruolo

Un Identity Provider (IdP) è un server che autentica gli utenti ed emette token. Nell'ecosistema OIDC, l'IdP fornisce due endpoint chiave: l'Authorization Endpoint per il login dell'utente e il Token Endpoint per scambiare il codice con token. Il client scopre gli indirizzi di questi endpoint tramite la Discovery URL — il percorso standard /.well-known/openid-configuration, che restituisce un documento JSON con tutta la configurazione del provider.

Ogni IdP pubblica il proprio JWKS (JSON Web Key Set) — un insieme di chiavi pubbliche per verificare la firma dell'ID Token. Il client memorizza nella cache queste chiavi e le utilizza per verificare ogni token ricevuto senza contattare il server.

Authorization Code Flow con PKCE

L'Authorization Code Flow è un processo a tre fasi. Prima, l'applicazione mobile genera un code verifier (una stringa casuale di 43–128 caratteri) e il suo hash — il code challenge. L'applicazione apre un browser o WebView con un URL contenente client_id, redirect_uri, scope (openid profile email) e code challenge. L'utente inserisce le credenziali nella pagina IdP e conferma il consenso. L'IdP reindirizza il browser all'applicazione con un authorization code.

Nella seconda fase, l'applicazione invia l'authorization code, il code verifier e il client_id al Token Endpoint del server. Il server verifica il code verifier rispetto al code challenge memorizzato e restituisce un ID Token, Access Token e opzionalmente un Refresh Token. Nella terza fase, l'applicazione verifica l'ID Token: valida la firma rispetto al JWKS, controlla l'issuer (iss), l'audience (aud) e il tempo di scadenza (exp). Se la verifica ha successo, l'utente è considerato autenticato.

PKCE (Proof Key for Code Exchange) elimina una vulnerabilità insita nell'Authorization Code Flow standard nei client pubblici. Poiché un'applicazione mobile non può memorizzare in modo sicuro un client secret, un attaccante che intercetta l'authorization code potrebbe scambiarlo per token. Il code verifier risolve questo problema: anche se il codice viene intercettato, senza il code verifier originale lo scambio è impossibile. Le OAuth Security Best Practices (RFC 9700) richiedono PKCE per tutti i client pubblici, incluse le applicazioni mobili.

ID Token e Access Token

OpenID Connect restituisce due token fondamentalmente diversi: l'ID Token e l'Access Token. L'ID Token è sempre un JWT che il client può leggere e verificare autonomamente. Contiene informazioni sull'utente e viene utilizzato per l'autenticazione, non per l'accesso alle API.

Struttura dell'ID Token

L'ID Token è costituito da header, payload e signature, codificati in Base64 e separati da punti. L'header contiene alg (algoritmo di firma) e kid (identificatore della chiave). Il payload include claim obbligatori: iss (issuer), sub (subject — ID univoco dell'utente), aud (audience — identificatore del client), exp (expiration), iat (issued at). I claim opzionali includono name, email, picture, locale.

Esempio di payload di ID Token decodificato da Google:

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890",
  "aud": "my-app-123.apps.googleusercontent.com",
  "exp": 1812345678,
  "iat": 1812342078,
  "name": "Ivan Petrov",
  "email": "ivan@example.com"
}

L'Access Token è un token opaco (stringa arbitraria) o JWT che il client passa nelle richieste API. A differenza dell'ID Token, l'access token non è destinato a essere letto dal client — il suo formato e contenuto sono noti solo al server delle risorse e al server di autorizzazione. L'Access Token ha uno scope — una restrizione di permesso — e una breve durata, tipicamente di 15–60 minuti.

Differenze tra OpenID Connect e OAuth 2.0

OAuth 2.0 è un framework di autorizzazione che definisce come un'applicazione ottiene l'accesso alle risorse dell'utente. OpenID Connect è un'estensione che aggiunge autenticazione a questo processo. La differenza principale: OAuth 2.0 non definisce un formato di token e non fornisce all'applicazione un modo per sapere chi ha effettivamente effettuato la richiesta.

Quando scegliere OpenID Connect

OpenID Connect è necessario quando l'applicazione deve identificare l'utente, non solo ottenere accesso ai suoi dati. Se utilizzi “Accedi con Google” o “Accedi con Apple” — questo è OIDC. Se la tua applicazione chiama un'API di terze parti per conto dell'utente senza bisogno di conoscerne l'identità — il puro OAuth 2.0 è sufficiente. Per i sistemi aziendali con Single Sign-On (SSO), la scelta è chiara: solo OpenID Connect, poiché fornisce logout standardizzato e gestione delle sessioni.

Implementazione di OpenID Connect nelle applicazioni mobili

L'integrazione di OpenID Connect in un'applicazione mobile richiede la scelta della libreria giusta e la corretta configurazione del flusso. Per Android, utilizza il gestore delle credenziali (AndroidX Credentials) o la libreria AppAuth. Per iOS, utilizza il framework AuthenticationServices con ASWebAuthenticationSession.

Esempio di codice in Kotlin (Android)

Di seguito è riportato un esempio di avvio dell'Authorization Code Flow con la libreria AppAuth-Android. L'applicazione crea una richiesta di autorizzazione, apre un browser per il login dell'utente e gestisce il callback con i token.

val authRequest = AuthorizationRequest.Builder(
    serviceConfig,
    clientId,
    "code",
    Uri.parse("com.example.app:/oauth")
)
.setScope("openid profile email")
.build()

val authService = AuthorizationService(this)
val intent = authService.getAuthorizationRequestIntent(authRequest)
startActivityForResult(intent, REQUEST_CODE)

override fun onActivityResult(
    requestCode: Int,
    resultCode: Int,
    data: Intent?
) {
    if (requestCode == REQUEST_CODE) {
        val response = AuthorizationResponse.fromIntent(data)
        if (response?.authorizationCode != null) {
            exchangeCodeForTokens(response.authorizationCode)
        }
    }
}

Esempio di codice in Swift (iOS)

L'ASWebAuthenticationSession di Apple fornisce un browser integrato per il flusso OIDC con supporto SSO tramite iCloud Keychain. La sessione si avvia con l'URL di autorizzazione e il callback viene gestito tramite un completion handler.

Quando si sceglie una libreria per OpenID Connect, considera il supporto PKCE integrato: AppAuth-Android e AppAuth-iOS supportano PKCE per impostazione predefinita. Firebase Authentication utilizza OIDC internamente per Google Sign-In, Sign in with Apple e Microsoft — lo sviluppatore non deve implementare il flusso manualmente. Per i sistemi aziendali con un IdP personalizzato (ad esempio, Keycloak o Okta), AppAuth rimane la scelta standard con il pieno controllo sulla configurazione e la gestione degli errori.

let authURL = URL("https://accounts.google.com/o/oauth2/v2/auth")!
let callbackURL = URL("com.example.app://oauth")!

let session = ASWebAuthenticationSession(
    url: authURL,
    callbackURLScheme: callbackURL.scheme!
) { url, error in
    guard let url = url else { return }
    let components = URLComponents(url: url)
    let code = components?.queryItems?.first(where: { $0.name == "code" })?.value
    if let code = code { exchangeCode(code) }
}
session.start()