Anatomia di un login.

1. Browser
2. App
3. IdP
4. API

1. Clic su "Accedi"

   Passo 1 di 7

   L’app non ha una sessione

   In parole semplici Come all’ingresso di un ufficio: prima di entrare ti mandano allo sportello che controlla i documenti.

   L’utente vuole entrare, ma l’app non controlla le password da sola. Delega l’autenticazione all’identity provider (IdP).

2. 302 → /authorize

   Passo 2 di 7

   Redirect con la challenge PKCE

   In parole semplici L’app ti accompagna allo sportello (l’IdP) con un biglietto sigillato: solo lei sa cosa c’è scritto dentro.

   L’app genera un code_verifier casuale, lo tiene per sé e invia solo il suo hash SHA-256 (code_challenge). state protegge da callback contraffatte, nonce lega il token a questa richiesta.

   GET https://idp.example.com/authorize
     ?response_type=code
     &client_id=web-app
     &redirect_uri=https://app.example.com/callback
     &scope=openid profile email
     &state=af0ifjsldkj
     &nonce=n-0S6_WzA2Mj
     &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
     &code_challenge_method=S256
   
   code_verifier (resta nell’app) = dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

3. password + codicefirma con passkey

   Passo 3 di 7

   Password e codice monousoPasskey

   In parole semplici Mostri il documento (la password) e una prova in più (il codice sul telefono).Il telefono garantisce per te con impronta o volto, e funziona solo sul sito vero.

   L’IdP verifica la password, poi chiede un codice monouso dall’app di autenticazione. Due fattori, ma entrambi si possono ancora rubare con una pagina falsa.Il dispositivo firma una challenge con una chiave privata legata a questo dominio, sbloccata con impronta o volto. Niente da digitare, niente da rubare su un sito clone.

4. 302 → /callback?code

   Passo 4 di 7

   Ritorno all’app con un code

   In parole semplici Lo sportello ti dà uno scontrino da ritirare: da solo non basta per entrare.

   L’IdP restituisce un code monouso e di breve durata. L’app controlla che state sia quello inviato. Il code da solo è inutile senza il verifier.

   GET https://app.example.com/callback
     ?code=SplxlOBeZQQYbYS6WxSbIA
     &state=af0ifjsldkj   ✓ state coincide

5. POST /token

   Passo 5 di 7

   Code + verifier in cambio dei token

   In parole semplici L’app consegna lo scontrino e il biglietto originale: se coincidono, riceve le chiavi.

   Da server a server, l’app invia il code e il code_verifier originale. L’IdP calcola l’hash del verifier e lo confronta con la challenge del passo 2. Un code rubato non supera questo controllo.

   POST https://idp.example.com/token
     grant_type=authorization_code
     &code=SplxlOBeZQQYbYS6WxSbIA
     &redirect_uri=https://app.example.com/callback
     &client_id=web-app
     &code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
   
   SHA-256(code_verifier) == code_challenge   ✓

6. id_token + access_token

   Passo 6 di 7

   Token emessi

   In parole semplici Le chiavi sono due: una carta d’identità per l’app (ID token) e un pass per l’API (access token).

   L’ID token dice all’app chi è l’utente e come ha fatto l’accesso. L’access token è per l’API. L’app verifica firma, iss, aud, exp e nonce prima di fidarsi.

   eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjIwMjYtMTAifQ.eyJpc3MiOiJodHRwczovL2lkcC5leGFtcGxlLmNvbSIsInN1YiI6IjI0ODI4OTc2MTAwMSIsImF1ZCI6IndlYi1hcHAiLCJleHAiOjE3NjAwMDM2MDAsImlhdCI6MTc2MDAwMDAwMCwiYXV0aF90aW1lIjoxNzU5OTk5OTk1LCJub25jZSI6Im4tMFM2X1d6QTJNaiIsImFtciI6WyJwd2QiLCJvdHAiLCJtZmEiXSwiYWNyIjoidXJuOmV4YW1wbGU6YWFsMiIsImVtYWlsIjoiYWRhQGV4YW1wbGUuY29tIn0.c2lnbmF0dXJlLW9mLWV4YW1wbGUCopia

   Claim dell’ID token

   • iss"https://idp.example.com"

     Chi ha emesso il token. Deve essere l’IdP di cui l’app si fida.

   • sub"248289761001"

     Id utente stabile e univoco presso questo IdP. Usalo come chiave, non l’email.

   • aud"web-app"

     A chi è destinato il token. L’app rifiuta token emessi per altri.

   • exp1760003600

     Scadenza come timestamp Unix. Dopo, il token non vale più.

   • iat1760000000

     Quando è stato emesso.

   • auth_time1759999995

     Quando l’utente si è davvero autenticato.

   • nonce"n-0S6_WzA2Mj"

     Deve coincidere con il valore del passo 2: blocca i token riutilizzati.

   • amr["pwd","otp","mfa"]

     Metodi di autenticazione usati. Cambia con il metodo scelto sopra.

   • acr"urn:example:aal2"

     Livello di garanzia raggiunto. Le app possono chiederne uno più alto per azioni a rischio.

   • email"ada@example.com"

     Un claim di profilo, rilasciato perché lo scope include email.

7. GET /me · Bearer

   Passo 7 di 7

   Chiamata all’API

   In parole semplici Con il pass l’app chiede i tuoi dati all’API, che controlla il pass ogni volta.

   L’API riceve solo l’access token. A ogni chiamata controlla firma, audience, scadenza e scope, e non vede mai la password.

   GET https://api.example.com/me
   Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJzY29wZSI6Im9wZW5pZCBwcm9maWxlIGVtYWlsIn0.…

Flusso completato.