--- term: 'OAuth 2.0 e login social' seoTitle: 'OAuth 2.0 e login social: flussi, token e PKCE' headline: 'Che cosa sono OAuth 2.0 e il login social?' slug: oauth-2-login-social category: auth-security shortDefinition: 'OAuth 2.0 è uno standard di autorizzazione che permette alle app di accedere a un account su un altro servizio: il login social si costruisce sopra.' relatedTerms: - json-web-token-jwt - passwordless-authentication - identity-access-management-iam - multi-factor-authentication-mfa contrastsWith: - json-web-token-jwt aboutTerms: - 'OAuth 2.0' - 'OpenID Connect (OIDC)' - 'Social Login' - 'PKCE' faq: - question: 'Che cos''è OAuth 2.0, in parole semplici?' answer: 'Uno standard che permette a un''app di ottenere un accesso limitato a un account su un altro servizio senza che la password le venga consegnata. Al posto delle credenziali, il servizio emette per l''app un token temporaneo e delimitato da scope – come la tessera di un albergo che apre la camera e la palestra ma non l''ufficio del direttore, e scade al check-out.' - question: 'OAuth è autorizzazione o autenticazione?' answer: 'Autorizzazione – lo dice il titolo stesso della specifica: la RFC 6749 si chiama "The OAuth 2.0 Authorization Framework". Risponde a "a che cosa può accedere questa app?", non a "chi è questo utente?". L''accesso costruito sopra OAuth è standardizzato da OpenID Connect, che aggiunge un ID token firmato con cui l''identità viene attestata all''app.' - question: 'Qual è la differenza tra OAuth 2.0 e OpenID Connect?' answer: 'OpenID Connect è un sottile strato di identità posato su OAuth 2.0: gli stessi flussi, più un ID token firmato (un JWT indirizzato all''app, con i claim issuer, subject, audience e nonce) e un endpoint userinfo. Ogni vero pulsante "Accedi con…" è OIDC o un equivalente proprietario del provider – OAuth da solo non definisce alcun modo di provare chi si è autenticato.' - question: 'Quali sono i grant type di OAuth?' answer: 'Authorization code con PKCE ogni volta che c''è di mezzo un utente; client credentials per il machine-to-machine; device authorization per televisori e CLI; refresh token per rinnovare l''accesso. I grant implicit e password sono legacy – entrambi rimossi in OAuth 2.1, e nessun progetto nuovo dovrebbe usarli.' - question: 'Che cosa sono gli access token e i refresh token?' answer: 'L''access token è la credenziale di breve durata che l''app presenta all''API: delimitata da scope, con scadenza, spesso un JWT. Il refresh token vive più a lungo e si scambia con nuovi access token senza chiedere di nuovo nulla all''utente; la pratica moderna lo ruota a ogni uso, così un token rubato muore al primo riutilizzo.' - question: 'Che cos''è PKCE e perché è obbligatorio?' answer: 'Proof Key for Code Exchange (si pronuncia "pixie"): l''app avvia il flusso con l''hash di un segreto e deve presentare l''originale quando riscatta l''authorization code, provando che chi riscatta è chi ha iniziato. Nato per le app mobili, incapaci di custodire un client secret, difende dall''intercettazione del codice – e la bozza di OAuth 2.1 lo richiede a quasi tutti i client.' - question: 'Che cos''è il login social e come funziona?' answer: 'È OIDC confezionato in un pulsante: l''app reindirizza all''endpoint di autorizzazione del provider; l''utente si autentica là – la password non tocca mai l''app – e acconsente; il provider reindirizza indietro con un codice monouso; l''app lo scambia con i token e legge il subject stabile dell''ID token per creare o ritrovare l''account locale.' - question: 'Il login social è sicuro?' answer: 'In generale sì: l''utente eredita l''autenticazione indurita e la MFA del provider invece di un''ennesima password riciclata. In cambio arrivano il rischio di concentrazione – un account provider bloccato o compromesso colpisce ogni app a valle – e la cura nell''implementazione: l''identità va ancorata al subject stabile del provider e a claim verificati, mai a un campo e-mail grezzo.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'RFC 6749 — The OAuth 2.0 Authorization Framework' url: 'https://datatracker.ietf.org/doc/html/rfc6749' - name: 'RFC 7636 — Proof Key for Code Exchange (PKCE)' url: 'https://datatracker.ietf.org/doc/html/rfc7636' - name: 'OAuth 2.1 — consolidation draft' url: 'https://oauth.net/2.1/' - name: 'OpenID Connect Core 1.0' url: 'https://openid.net/specs/openid-connect-core-1_0.html' - name: 'OAuth — Wikipedia' url: 'https://en.wikipedia.org/wiki/OAuth' cta: title: 'Il login social senza la danza dei redirect' text: 'Back4app avvolge tutto il flusso: passa all''SDK i token di un provider e logInWith li verifica lato server, crea o ritrova l''utente ed emette la tua sessione – con linkWith che risolve il collegamento degli account in una sola chiamata.' linkText: 'Inizia gratis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-10-06' translationKey: oauth-2-social-login --- **OAuth 2.0 è uno standard di autorizzazione che permette alle app di accedere a un account su un altro servizio: il login social si costruisce sopra.** I due vengono quasi sempre spiegati separatamente, ed è così che la confusione sopravvive: la [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749) definisce l'impianto (accesso delegato e delimitato da scope, senza condividere password), OpenID Connect aggiunge lo strato di identità, e il pulsante "Accedi con…" è la feature di prodotto che viaggia su entrambi. ## Punti chiave | Domanda | Risposta | | --- | --- | | OAuth 2.0 | Autorizzazione delegata: token delimitati da scope e con scadenza al posto delle password | | La confusione | OAuth risponde *a che cosa può accedere questa app* – OIDC risponde *chi è questo utente* | | Il flusso moderno | Authorization code + PKCE – i grant implicit e password sono spariti in 2.1 | | I token | Access (breve, delimitato) · refresh (ruotato) · ID (claim di identità firmati) | | Login social | OIDC in un pulsante: il provider autentica, l'app riceve claim verificati | ## Il flusso authorization code, passo per passo La danza dei redirect dietro ogni schermata di consenso – con i parametri che contano: ```text 1 App → provider /authorize?client_id=…&redirect_uri=…&scope=profile &state=af3G… ← guardia anti-CSRF, verificata al ritorno &code_challenge=hK9… ← PKCE: hash di un segreto appena creato 2 Utente ↔ provider Accede LÀ (la password non tocca mai l'app), acconsente 3 Provider → app redirect_uri?code=SplxlO…&state=af3G… ← codice monouso 4 App → provider POST /token { code, code_verifier } ← prova PKCE Provider → app { access_token, refresh_token, id_token } 5 App → API Authorization: Bearer ``` Ecco che cosa diventa quando un backend lo avvolge – entrano i token del provider, esce una sessione verificata: **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // Social login: the provider's tokens become a user session const user = await Parse.User.logInWith('apple', { authData: { id: appleUserId, token: identityToken }, }); // First login creates the user; later logins match — session token issued // Account linking: attach a second provider to the same user await user.linkWith('facebook', { authData: fbAuthData }); ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // Social login: the provider's tokens become a user session final user = ParseUser.forQuery(); final response = await user.loginWith( 'apple', apple(identityToken, appleUserId), ); // First login creates the user; later logins match — session token issued // Account linking: attach a second provider to the same user await user.linkWith('facebook', facebook(token, fbUserId, expiresAt)); ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // Social login: the provider's tokens become a user session let user = try await User.apple.login( user: appleUserId, identityToken: identityTokenData ) // First login creates the user; later logins match — session token issued // Account linking: attach a second provider to the same user try await user.facebook.link(userId: fbUserId, accessToken: fbAccessToken) ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // Social login: the provider's tokens become a user session val authData = mapOf("id" to appleUserId, "token" to identityToken) ParseUser.logInWithInBackground("apple", authData).continueWith { task -> val user = task.result // First login creates the user; later logins match — session token issued // Account linking: attach a second provider to the same user user.linkWithInBackground("facebook", fbAuthData) } ``` ## I quattro ruoli | Ruolo | Chi è | In termini di "Accedi con…" | | --- | --- | --- | | Resource owner | L'utente | Chi usa l'app | | Client | L'app che chiede l'accesso | L'app che mostra il pulsante | | Authorization server | Emette codici e token | Le pagine di accesso dell'identity provider | | Resource server | L'API che custodisce i dati | L'API di profilo/utente del provider | ```mermaid flowchart LR accTitle: Flusso authorization code di OAuth 2.0 con PKCE accDescr: L'app client reindirizza l'utente all'authorization server con un challenge PKCE; l'utente si autentica e acconsente là; il server reindirizza indietro con un codice monouso; il client scambia il codice più il verifier PKCE con access token, refresh token e ID token, poi chiama il resource server con l'access token. U["Utente
(resource owner)"] -->|"1 · reindirizzato con
state + code_challenge"| AS["Authorization server
accesso + consenso"] AS -->|"2 · codice monouso"| C["App client"] C -->|"3 · code + code_verifier"| AS AS -->|"4 · access · refresh · ID token"| C C -->|"5 · Bearer access_token"| RS["Resource server
(API)"] ``` ## Grant type: quale flusso, e che cosa ha cambiato OAuth 2.1 | Grant | Per | Utente presente? | Stato in [OAuth 2.1](https://oauth.net/2.1/) | | --- | --- | --- | --- | | Authorization code + PKCE | Web, mobile, SPA – tutto ciò che coinvolge un utente | Sì | **La scelta predefinita – PKCE richiesto a quasi tutti i client** | | Client credentials | Machine-to-machine, account di servizio | No | Mantenuto | | Device authorization | Televisori, console, CLI | Sì, su un secondo dispositivo | Mantenuto | | Refresh token | Rinnovare l'accesso in silenzio | No | Mantenuto – rotazione o sender-constraining richiesti ai client pubblici | | Implicit | SPA legacy (token nei frammenti di URL) | Sì | **Rimosso** | | Password (ROPC) | L'app raccoglie da sé la password | Sì | **Rimosso** – vanifica l'intero senso dell'operazione | OAuth 2.1 è consolidamento, non rivoluzione: le rimozioni qui sopra, più i redirect URI a corrispondenza esatta e il divieto di bearer token nelle query string – le lezioni di sicurezza accumulate in un decennio, ripiegate in un unico documento. Le spiegazioni definitorie per la maggior parte non hanno recuperato il ritardo; diverse insegnano ancora il flusso implicit senza alcun avvertimento. ## OAuth vs. OpenID Connect: autorizzazione vs. autenticazione La frase che tutti ripetono – "OAuth non è autenticazione" – merita il suo meccanismo, perché è il meccanismo a rendere sfruttabile un accesso ingenuo: | | Access token (OAuth) | ID token (OIDC) | | --- | --- | --- | | Indirizzato a | Il resource server (API) | **L'app** (`aud` = il suo client ID) | | Prova | Questo portatore può accedere a questi scope | Questo utente (`sub`) si è autenticato presso questo emittente (`iss`), adesso (`iat`/`exp`), per questo accesso (`nonce`) | | Formato | Spesso opaco per il client | [JWT](/glossary/it/json-web-token-jwt/) firmato che l'app deve validare | | Si può usare per l'accesso? | **No** – qualunque app autorizzata dall'utente ne possiede uno; non dice nulla su chi è presente | Sì – è esattamente il suo mestiere | "Accedere con un semplice access token" fallisce perché gli access token sono prova trasferibile di *permesso*, non di *presenza*: un'app malevola che abbia ottenuto un token per i propri scopi potrebbe riutilizzarlo altrove per impersonare l'utente. [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html) esiste proprio per chiudere quella falla – gli stessi flussi, più un'attestazione di identità legata crittograficamente all'app. ## Login social: il pulsante sopra l'impianto Il login social è OIDC confezionato come UX: il provider autentica, l'app riceve claim verificati e crea o ritrova un account – nessuna password archiviata, nessun flusso di reimpostazione da mantenere, la MFA del provider ereditata gratis. I trade-off di prodotto meritano numeri onesti. Le promesse di un 20–50 % di registrazioni in più sono folklore dei fornitori; i test controllati hanno misurato piuttosto un 3 %, anche se oggi circa un terzo degli accessi consumer arriva per via social – gli utenti vogliono chiaramente l'opzione. Le pratiche che spostano davvero la conversione: offrire **due o tre provider** che il pubblico usa per davvero (la griglia di partenza di pulsanti danneggia in modo misurabile), tenere sempre un'alternativa via e-mail, e sapere che i redirect OAuth si rompono dentro le WebView incorporate – una causa reale di iscrizioni mobili fallite. Due fatti specifici di un provider pesano abbastanza da essere nominati: **Sign in with Apple** emette indirizzi di relay privato (`…@privaterelay.appleid.com`), quindi il collegamento basato su e-mail e le liste di distribuzione devono aspettarsi alias opachi – e le regole dell'App Store impongono alle app che offrono un accesso di terze parti di offrire anche un'opzione di accesso rispettosa della privacy. ## Collegamento degli account e la trappola dell'e-mail La stessa persona arriverà da due provider, e entrambi dichiareranno `ada@example.com`. La regola che evita la vulnerabilità classica: **l'identità si ancora all'identificatore `sub` stabile del provider, mai alla sola e-mail.** Le e-mail cambiano, vengono riciclate e – ecco il bordo tagliente – non sono sempre verificate: una classe di vulnerabilità emersa nel 2023 ha mostrato che le app che si fidavano di un claim e-mail non verificato nei token di un grande provider erano esposte al furto dell'account da parte di chiunque potesse impostare quella e-mail sul proprio account provider. Conviene collegare automaticamente solo su e-mail che il provider attesta come verificate; altrimenti si chiede all'utente di collegare in modo esplicito. E va previsto anche l'uscita: chi resta bloccato fuori da un provider (succede senza preavviso) perde ogni app a valle, a meno che non gli sia stato offerto un secondo metodo collegato – ed è per questo che "un solo metodo di accesso per utente" è una fabbrica di ticket di supporto travestita da semplicità. ## Casi d'uso tipici - **Accesso alle app consumer** – il login social canonico: meno attrito, MFA ereditata, nessun archivio di password da far violare. - **Accesso ad API di terze parti** – il caso OAuth originale: un'app di agenda che legge il calendario senza la password. - **Autenticazione machine-to-machine** – client credentials fra servizi, senza alcun utente in vista. - **Identità multi-provider** – un account, diversi metodi di accesso collegati, scollegamento e recupero per singolo utente. - **Ponte verso l'SSO aziendale** – lo stesso pattern OIDC puntato su un identity provider del personale invece che su uno social. ## Conviene offrire il login social? Matrice decisionale | Situazione | Orientamento | | --- | --- | | App consumer, pubblico fortemente mobile | Sì – 2 o 3 provider + alternativa via e-mail | | App iOS che offre un accesso di terze parti | Un'opzione di accesso rispettosa della privacy è obbligatoria – prevedere le e-mail di relay | | Prodotto B2B o aziendale | OIDC sì, ma verso l'[SSO](/glossary/it/single-sign-on-sso/) del personale, non verso il social | | Dati regolamentati, ciclo di vita degli account rigido | Prudenza – il blocco presso il provider e la verifica d'identità chiedono risposte | | MVP che ha bisogno di autenticazione questa settimana | Sì, tramite un backend che avvolge i flussi | | Utenti senza account presso i grandi provider | Prima e-mail o passwordless; il social come opzione | ## Limiti e trade-off - **Si ereditano le decisioni del provider.** Schermate di consenso, durata delle sessioni, recupero degli account e deprecazioni arrivano secondo il suo calendario, non secondo il proprio. - **Il rischio di concentrazione è reale.** Un disservizio del provider o un account bloccato è un'interruzione dell'accesso; i metodi di riserva collegati sono la mitigazione, non un extra facoltativo. - **La flessibilità di OAuth è la sua debolezza storica.** Un framework con opzioni invita combinazioni insicure – 2.1 esiste perché flussi implicit, redirect con jolly e refresh token senza rotazione continuavano ad andare in produzione. - **I flussi di redirect hanno bordi taglienti.** `state` (CSRF), i redirect URI esatti (open redirect e furto del codice) e PKCE (intercettazione) sono ciascuno a un parametro dimenticato di distanza da un incidente. - **I claim social sono un pavimento, non un profilo.** Arrivano subject, e-mail, nome – gli attributi oltre quelli richiedono comunque un onboarding proprio, e i relay per la privacy fanno sì che anche l'e-mail possa essere un alias. ## OAuth e login social su Back4app Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. I flussi qui sopra si ripiegano nelle schede di codice: il client ottiene nativamente i token del provider, li passa a `logInWith`, e gli adattatori di autenticazione di Back4app li verificano lato server presso il provider prima di creare o ritrovare lo `User` – le identità dei provider vivono in blocchi `authData` per singolo provider, indicizzati sul subject stabile, che è la regola di collegamento degli account imposta per costruzione. `linkWith` aggancia provider aggiuntivi (o una credenziale e-mail) allo stesso utente, rispondendo al problema del blocco in una sola chiamata, e il token di sessione che l'app riceve funziona poi su tutte le API REST, GraphQL e Live Query, con le [ACL](/glossary/it/liste-di-controllo-degli-accessi-acl/) e i permessi a livello di classe a decidere che cosa possa toccare. La danza dei redirect, la verifica dei token e i casi limite del collegamento arrivano come comportamento di piattaforma – i provider si configurano nella dashboard e resta da spedire il pulsante.