Che cosa sono OAuth 2.0 e il login social?

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 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

Il flusso authorization code, passo per passo

La danza dei redirect dietro ogni schermata di consenso – con i parametri che contano:

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 <access_token>

Ecco che cosa diventa quando un backend lo avvolge – entrano i token del provider, esce una sessione verificata:

// 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 — 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));

// 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)

// 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

Grant type: quale flusso, e che cosa ha cambiato OAuth 2.1

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:

“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 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 [email protected]. 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

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 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.