Qu'est-ce qu'un adaptateur de connexion sociale ?

Un adaptateur de connexion sociale est un composant backend qui vérifie les tokens d’un fournisseur d’identité et en tire un utilisateur et une session. C’est le chaînon manquant de toutes les explications sur la connexion sociale : OAuth 2.0 décrit comment le client obtient les tokens du fournisseur, mais quelque chose de votre côté doit encore vérifier ces tokens, décider à quel compte ils appartiennent et émettre une session à laquelle vos API font confiance. Ce quelque chose, c’est l’adaptateur.

Points clés

L’adaptateur en action

Des tokens de fournisseur en entrée, une session vérifiée en sortie — plus le flow de conversion d’un invité :

// JavaScript / Node.js — Back4app JS SDK
// The adapter path: provider tokens in, verified session out.
// The platform verifies the token with the provider before any user exists.
const user = await Parse.User.logInWith('apple', {
  authData: { id: providerUserId, token: identityToken },
});
// user.authData holds the provider block, keyed on the stable subject ID

// Anonymous → identified: upgrade the guest without losing its objects
const guest = await Parse.AnonymousUtils.logIn();
await guest.linkWith('apple', {
  authData: { id: providerUserId, token: identityToken },
});

// Flutter / Dart — Back4app Flutter SDK
// The adapter path: provider tokens in, verified session out
final user = ParseUser.forQuery();
final response = await user.loginWith(
  'apple',
  apple(identityToken, providerUserId),
);
// First login creates the user; later logins match the same authData

// Anonymous → identified: upgrade the guest without losing its objects
final guest = ParseUser.forQuery();
await guest.loginAnonymous();
await guest.linkWith('apple', apple(identityToken, providerUserId));

// iOS / Swift — Back4app Swift SDK
// The adapter path: provider tokens in, verified session out
let user = try await User.apple.login(
    user: providerUserId,
    identityToken: tokenData
)
// First login creates the user; later logins match the same authData

// Anonymous → identified: upgrade the guest without losing its objects
let guest = try await User.anonymous.login()
let upgraded = try await guest.apple.link(
    user: providerUserId,
    identityToken: tokenData
)

// Android / Kotlin — Back4app Android SDK
// The adapter path: provider tokens in, verified session out
val authData = mapOf("id" to providerUserId, "token" to identityToken)
ParseUser.logInWithInBackground("apple", authData).continueWith { task ->
    val user = task.result // created on first login, matched afterwards
}

// Anonymous → identified: upgrade the guest without losing its objects
ParseAnonymousUtils.logIn { guest, e ->
    if (e == null && guest != null) {
        guest.linkWithInBackground("apple", authData)
    }
}

Ce que fait réellement l’adaptateur

Le rôle du client dans la connexion sociale s’arrête quand un grand fournisseur d’identité lui remet des tokens. Celui de l’adaptateur commence là, et il se joue entièrement côté serveur :

L’étape 4 est celle que les implémentations maison sautent à leurs risques et périls : l’adaptateur interroge le fournisseur pour confirmer que le token est authentique, non expiré et émis pour cette app — une « vérification » côté client ne prouve rien, puisque n’importe quelle requête peut revendiquer n’importe quelle identité. L’étape 5 encode la règle de liaison de comptes qui empêche la prise de contrôle classique : la correspondance se fait sur l’identifiant stable du sujet chez le fournisseur, jamais sur un claim d’e-mail. Le résultat, dans la table des utilisateurs, est une map authData — un bloc vérifié par fournisseur lié, tous pointant vers un seul utilisateur dont les objets, les ACL et les sessions se comportent exactement comme si le compte avait un mot de passe.

Adaptateur d’authentification vs. OAuth fait maison

Le point à retenir : l’adaptateur ne remplace pas OAuth — le client exécute toujours le flow du fournisseur, et PKCE compte toujours. Il remplace tout ce que vous auriez autrement à construire après l’arrivée des tokens, c’est-à-dire là où se trouvent en réalité la plupart des vulnérabilités de la connexion sociale.

La liaison de comptes, et la conversion qui sauve votre onboarding

Deux flows distinguent une authentification basée sur des adaptateurs d’un simple endpoint « vérifier un token ». Liaison de comptes : la même personne arrive par des boutons différents — l’appel de liaison rattache le bloc vérifié d’un second fournisseur à l’utilisateur connecté, si bien que chaque fournisseur mène au même compte et qu’un blocage chez un fournisseur ne signifie plus un client perdu. Conversion d’un anonyme : les apps qui laissent les invités agir tout de suite adossent chaque invité à un utilisateur anonyme ; quand l’utilisateur se connecte enfin, la liaison le convertit sur place — même object ID, donc le panier, la progression et les permissions par objet sont tous conservés. Les équipes qui repoussent ainsi l’inscription suppriment leur écran le plus dissuasif sans qu’un script de migration les attende au bout. Le même mécanisme fonctionne en sens inverse pour la déliaison, ce qui permet aux utilisateurs de retirer un fournisseur sans perdre leur compte — les configurations de single sign-on s’en servent pour regrouper les identités sous un fournisseur d’entreprise.

Cas d’usage courants

• Connexion grand public via les principaux fournisseurs d’identité — les boutons habituels, avec vérification, correspondance et sessions gérées une seule fois, de manière uniforme.
• Onboarding « invité d’abord » — des utilisateurs anonymes convertis sur place au moment de l’engagement, sans perte de données.
• Comptes multi-fournisseurs — un utilisateur, plusieurs méthodes de connexion liées, déliaison par utilisateur ; la réponse au blocage chez un fournisseur.
• Passerelles d’identité d’entreprise — un adaptateur personnalisé branché sur un système d’IAM d’entreprise plutôt que sur un fournisseur social.
• Continuité entre appareils — la session de plateforme fonctionne avec REST, GraphQL et les live queries, quel que soit le fournisseur qui l’a ouverte.

Devriez-vous utiliser un adaptateur d’authentification ou construire le flow vous-même ? Matrice de décision

Limites et trade-offs

• Vous héritez de la liste de fournisseurs de la plateforme. Les fournisseurs grand public sont couverts ; un fournisseur de niche implique d’écrire un adaptateur personnalisé ou d’attendre la roadmap.
• Le flow côté client reste à votre charge. L’adaptateur commence à la soumission des tokens — UX de connexion native, redirections et PKCE restent du travail client, et les restrictions des WebView intégrées aux apps posent toujours problème.
• La politique des fournisseurs se répercute. Écrans de consentement, formats de tokens, adresses e-mail relais et dépréciations évoluent au rythme du fournisseur ; l’adaptateur absorbe la mécanique, pas la politique.
• Le débogage implique trois parties. Une connexion qui échoue peut venir du flow client, de l’appel de vérification de l’adaptateur ou du fournisseur — de bons logs à la frontière de l’adaptateur valent la peine d’être mis en place dès le premier jour.
• L’uniformité a son revers. L’adaptateur ramène chaque fournisseur à un identifiant de sujet et un profil ; si votre app a besoin de données poussées propres à un fournisseur, vous appellerez de toute façon ses API séparément.

Adaptateurs de 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. Ses adaptateurs d’authentification implémentent tout ce que décrit cet article sous forme de comportement de la plateforme : logInWith vérifie les tokens du fournisseur côté serveur et crée ou retrouve l’utilisateur via l’identifiant stable du sujet, linkWith gère sur place aussi bien la liaison de comptes que la conversion des utilisateurs anonymes, et la session obtenue fonctionne sur toutes les API, les CLP et les ACL décidant de ce qu’elle peut toucher. Les fournisseurs se configurent dans le dashboard, et l’interface des adaptateurs est ouverte — un fournisseur personnalisé est un petit module de vérification, pas un fork de votre stack d’authentification.