Qu'est-ce qu'OAuth 2.0 et la connexion sociale ?

OAuth 2.0 est un standard d’autorisation qui laisse une app accéder à votre compte sur un autre service — la connexion sociale s’appuie dessus. Les deux sont presque toujours expliqués séparément, et c’est ainsi que la confusion survit : la RFC 6749 définit la plomberie (accès délégué et à portée limitée, sans partage de mot de passe), OpenID Connect ajoute la couche d’identité, et le bouton “Se connecter avec…” est la feature produit qui roule sur les deux.

Points clés

Le flux authorization code, étape par étape

La danse des redirections derrière chaque écran de consentement — avec les paramètres qui comptent :

1  App → fournisseur          /authorize?client_id=…&redirect_uri=…&scope=profile
                              &state=af3G…            ← garde anti-CSRF, vérifiée au retour
                              &code_challenge=hK9…    ← PKCE : hash d'un secret tout neuf

2  Utilisateur ↔ fournisseur  Se connecte LÀ (le mot de passe ne touche jamais l'app), consent

3  Fournisseur → app          redirect_uri?code=SplxlO…&state=af3G…   ← code à usage unique

4  App → fournisseur          POST /token  { code, code_verifier }    ← preuve PKCE
   Fournisseur → app          { access_token, refresh_token, id_token }

5  App → API                  Authorization: Bearer <access_token>

Voilà ce que cela donne quand un backend l’enveloppe — les tokens du fournisseur entrent, une session vérifiée sort :

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

Les quatre rôles

Grant types : quel flux, et ce qu’OAuth 2.1 a changé

OAuth 2.1 est une consolidation, pas une révolution : les suppressions ci-dessus, plus des redirect URI à correspondance exacte et l’interdiction des bearer tokens dans les query strings — les leçons de sécurité accumulées en une décennie, repliées dans un seul document. Les explications définitionnelles n’ont pour l’essentiel pas suivi ; plusieurs enseignent encore le flux implicit sans le moindre avertissement.

OAuth vs. OpenID Connect : autorisation vs. authentification

La phrase que tout le monde répète — “OAuth n’est pas de l’authentification” — mérite son mécanisme, parce que c’est le mécanisme qui rend une connexion naïve exploitable :

“Se connecter avec un simple access token” échoue parce qu’un access token est une preuve transférable de permission, pas de présence : une app malveillante ayant obtenu un token pour ses propres besoins pourrait le rejouer ailleurs pour se faire passer pour l’utilisateur. OpenID Connect existe précisément pour combler cet écart — les mêmes flux, plus une assertion d’identité liée cryptographiquement à votre app.

La connexion sociale : le bouton posé sur la plomberie

La connexion sociale, c’est de l’OIDC emballé en UX : le fournisseur authentifie, votre app reçoit des claims vérifiés et crée ou retrouve un compte — aucun mot de passe stocké, aucun flux de réinitialisation à maintenir, la MFA du fournisseur héritée gratuitement. Les trade-offs produit méritent des chiffres honnêtes. Les promesses de 20 à 50 % d’inscriptions en plus relèvent du folklore commercial ; les tests contrôlés mesurent plutôt 3 %, même si près d’un tiers des connexions grand public arrivent aujourd’hui par la voie sociale — signe que les utilisateurs veulent l’option. Les pratiques qui font réellement bouger la conversion : proposez deux ou trois fournisseurs que votre audience utilise vraiment (la grille de départ de boutons nuit de façon mesurable), gardez toujours une alternative par e-mail, et sachez que les redirections OAuth cassent à l’intérieur des WebViews embarquées — une cause réelle d’échecs d’inscription sur mobile. Deux faits propres à un fournisseur pèsent assez pour être nommés : Sign in with Apple émet des adresses de relais privé (…@privaterelay.appleid.com), donc la liaison par e-mail et les listes de diffusion doivent s’attendre à des alias opaques — et les règles de l’App Store imposent aux apps proposant une connexion tierce de proposer aussi une option de connexion respectueuse de la vie privée.

Liaison de comptes et le piège de l’e-mail

La même personne arrivera par deux fournisseurs, et tous deux annonceront [email protected]. La règle qui évite la vulnérabilité classique : l’identité s’ancre sur l’identifiant sub stable du fournisseur, jamais sur l’e-mail seul. Les e-mails changent, sont recyclés et — le vrai tranchant — ne sont pas toujours vérifiés : une classe de vulnérabilités révélée en 2023 a montré que les apps faisant confiance à un claim d’e-mail non vérifié dans les tokens d’un grand fournisseur étaient ouvertes au vol de compte par quiconque pouvait fixer cet e-mail sur son propre compte. Ne liez automatiquement que sur des e-mails que le fournisseur atteste comme vérifiés ; sinon, demandez à l’utilisateur de lier explicitement. Et anticipez la sortie : un utilisateur bloqué chez un fournisseur (cela arrive sans prévenir) perd toutes les apps en aval, sauf si vous lui avez proposé une seconde méthode liée — c’est pourquoi “une seule méthode de connexion par utilisateur” est une machine à tickets de support déguisée en simplicité.

Cas d’usage courants

• Connexion aux apps grand public — la connexion sociale canonique : moins de friction, MFA héritée, aucune base de mots de passe à faire fuiter.
• Accès à des API tierces — le cas OAuth d’origine : une app d’agenda qui lit votre calendrier sans votre mot de passe.
• Authentification machine à machine — client credentials entre services, sans le moindre utilisateur en vue.
• Identité multifournisseur — un compte, plusieurs méthodes de connexion liées, dissociation et récupération par utilisateur.
• Passerelle vers le SSO d’entreprise — le même pattern OIDC pointé vers un fournisseur d’identité d’entreprise plutôt que social.

Devriez-vous proposer la connexion sociale ? Matrice de décision

Limites et trade-offs

• Vous héritez des décisions du fournisseur. Écrans de consentement, durée des sessions, récupération de compte et dépréciations arrivent à son calendrier, pas au vôtre.
• Le risque de concentration est réel. Une panne du fournisseur ou un compte bloqué, c’est votre connexion en panne ; les méthodes de secours liées sont la mitigation, pas un supplément facultatif.
• La souplesse d’OAuth est sa faiblesse historique. Un framework à options invite les combinaisons non sûres — si 2.1 existe, c’est que les flux implicit, les redirections avec jokers et les refresh tokens sans rotation continuaient de partir en production.
• Les flux de redirection ont des angles vifs. state (CSRF), les redirect URI exactes (open redirect et vol de code) et PKCE (interception) sont chacun à un paramètre oublié d’un incident.
• Les claims sociaux sont un plancher, pas un profil. Vous recevez subject, e-mail, nom — les attributs au-delà demandent toujours votre propre onboarding, et les relais de confidentialité font que même l’e-mail peut être un alias.

OAuth et la connexion sociale sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Les flux ci-dessus se replient dans les onglets de code : le client obtient nativement les tokens du fournisseur, les passe à logInWith, et les adaptateurs d’authentification de Back4app les vérifient côté serveur auprès du fournisseur avant de créer ou de retrouver le User — les identités de fournisseur vivent dans des blocs authData par fournisseur, indexés sur le subject stable, ce qui impose la règle de liaison de comptes par construction. linkWith rattache des fournisseurs supplémentaires (ou un identifiant e-mail) au même utilisateur, réglant le problème du blocage en un seul appel, et le token de session que votre app reçoit fonctionne ensuite sur les API REST, GraphQL et Live Query, avec les ACL et les permissions de classe qui décident de ce qu’il peut toucher. La danse des redirections, la vérification des tokens et les cas limites de liaison arrivent comme des comportements de plateforme — vous configurez les fournisseurs dans le dashboard et vous livrez le bouton.