--- term: 'OAuth 2.0 et Connexion Sociale' seoTitle: 'OAuth 2.0 et connexion sociale : flux, tokens, PKCE, liaison de comptes' headline: "Qu'est-ce qu'OAuth 2.0 et la connexion sociale ?" slug: oauth-2-connexion-sociale category: auth-security shortDefinition: "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." 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: "Qu'est-ce qu'OAuth 2.0 en termes simples ?" answer: "Un standard qui permet à une app d'obtenir un accès limité à votre compte sur un autre service sans que vous lui confiiez votre mot de passe. À la place de vos identifiants, le service émet pour l'app un token temporaire et à portée limitée — comme une carte d'hôtel qui ouvre votre chambre et la salle de sport, mais pas le bureau du directeur, et qui expire au départ." - question: "OAuth, c'est de l'autorisation ou de l'authentification ?" answer: "De l'autorisation — le titre même de la spécification le dit, la RFC 6749 s'appelle \"The OAuth 2.0 Authorization Framework\". Elle répond à \"à quoi cette app peut-elle accéder ?\", pas à \"qui est cet utilisateur ?\". La connexion par-dessus OAuth est standardisée par OpenID Connect, qui ajoute un ID token signé attestant l'identité auprès de l'app." - question: 'Quelle est la différence entre OAuth 2.0 et OpenID Connect ?' answer: "OpenID Connect est une fine couche d'identité posée sur OAuth 2.0 : les mêmes flux, plus un ID token signé (un JWT adressé à votre app, avec les claims issuer, subject, audience et nonce) et un endpoint userinfo. Tout vrai bouton \"Se connecter avec…\" est de l'OIDC ou un équivalent propre au fournisseur — OAuth seul ne définit aucun moyen de prouver qui s'est connecté." - question: "Quels sont les grant types d'OAuth ?" answer: "Authorization code avec PKCE dès qu'un utilisateur est impliqué ; client credentials pour le machine à machine ; device authorization pour les téléviseurs et les CLI ; refresh token pour renouveler l'accès. Les grants implicit et password sont du legacy — tous deux supprimés dans OAuth 2.1, et aucune conception nouvelle ne devrait les utiliser." - question: 'Que sont les access tokens et les refresh tokens ?' answer: "L'access token est l'identifiant à durée de vie courte que l'app présente à l'API — à portée limitée, avec expiration, souvent un JWT. Le refresh token vit plus longtemps et s'échange contre de nouveaux access tokens sans rien redemander à l'utilisateur ; la pratique moderne le fait tourner à chaque usage, pour qu'un token volé meure au premier rejeu." - question: "Qu'est-ce que PKCE et pourquoi est-il obligatoire ?" answer: "Proof Key for Code Exchange (prononcé \"pixie\") : l'app démarre le flux avec le hash d'un secret et doit présenter l'original au moment d'échanger l'authorization code, prouvant que celui qui échange est bien celui qui a initié. Conçu pour les apps mobiles, incapables de garder un client secret, il défend contre l'interception de code — et le brouillon d'OAuth 2.1 l'exige de presque tous les clients." - question: "Qu'est-ce que la connexion sociale et comment fonctionne-t-elle ?" answer: "C'est de l'OIDC emballé dans un bouton : l'app redirige vers l'endpoint d'autorisation du fournisseur ; l'utilisateur s'authentifie là-bas — le mot de passe ne touche jamais l'app — et consent ; le fournisseur redirige avec un code à usage unique ; l'app l'échange contre des tokens et lit le subject stable de l'ID token pour créer ou retrouver le compte local." - question: 'La connexion sociale est-elle sûre ?' answer: "Globalement oui : l'utilisateur hérite de l'authentification durcie et de la MFA du fournisseur au lieu d'un énième mot de passe réutilisé. Les contreparties sont le risque de concentration — un compte fournisseur bloqué ou compromis affecte toutes les apps en aval — et le soin apporté à l'implémentation : l'app doit ancrer l'identité sur le subject stable du fournisseur et sur des claims vérifiés, jamais sur un champ e-mail brut." 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: 'La connexion sociale sans la danse des redirections' text: "Back4app enveloppe tout le flux : passez au SDK les tokens d'un fournisseur et logInWith les vérifie côté serveur, crée ou retrouve l'utilisateur et émet votre session — avec linkWith qui règle la liaison de comptes en un seul appel." linkText: 'Commencez gratuitement' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-10' translationKey: oauth-2-social-login --- **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](https://datatracker.ietf.org/doc/html/rfc6749) 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 | Question | Réponse | | --- | --- | | OAuth 2.0 | Autorisation déléguée : des tokens à portée limitée et périssables au lieu de mots de passe | | La confusion | OAuth répond *à quoi cette app peut-elle accéder* — OIDC répond *qui est cet utilisateur* | | Le flux moderne | Authorization code + PKCE — les grants implicit et password ont disparu en 2.1 | | Les tokens | Access (court, à portée limitée) · refresh (avec rotation) · ID (claims d'identité signés) | | Connexion sociale | De l'OIDC dans un bouton : le fournisseur authentifie, votre app reçoit des claims vérifiés | ## Le flux authorization code, étape par étape La danse des redirections derrière chaque écran de consentement — avec les paramètres qui comptent : ```text 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 ``` Voilà ce que cela donne quand un backend l'enveloppe — les tokens du fournisseur entrent, une session vérifiée sort : **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) } ``` ## Les quatre rôles | Rôle | Qui c'est | En termes de "Se connecter avec…" | | --- | --- | --- | | Resource owner | L'utilisateur | Vous | | Client | L'app qui demande l'accès | L'app qui affiche le bouton | | Authorization server | Émet les codes et les tokens | Les pages de connexion du fournisseur d'identité | | Resource server | L'API qui garde les données | L'API de profil/utilisateur du fournisseur | ```mermaid flowchart LR accTitle: Flux authorization code d'OAuth 2.0 avec PKCE accDescr: L'app cliente redirige l'utilisateur vers l'authorization server avec un challenge PKCE ; l'utilisateur s'authentifie et consent là-bas ; le serveur redirige avec un code à usage unique ; le client échange le code et le verifier PKCE contre des access, refresh et ID tokens, puis appelle le resource server avec l'access token. U["Utilisateur
(resource owner)"] -->|"1 · redirigé avec
state + code_challenge"| AS["Authorization server
connexion + consentement"] AS -->|"2 · code à usage unique"| C["App cliente"] C -->|"3 · code + code_verifier"| AS AS -->|"4 · access · refresh · ID tokens"| C C -->|"5 · Bearer access_token"| RS["Resource server
(API)"] ``` ## Grant types : quel flux, et ce qu'OAuth 2.1 a changé | Grant | Pour | Utilisateur présent ? | Statut dans [OAuth 2.1](https://oauth.net/2.1/) | | --- | --- | --- | --- | | Authorization code + PKCE | Web, mobile, SPA — tout ce qui implique un utilisateur | Oui | **Le choix par défaut — PKCE exigé de presque tous les clients** | | Client credentials | Machine à machine, comptes de service | Non | Conservé | | Device authorization | Téléviseurs, consoles, CLI | Oui, sur un second appareil | Conservé | | Refresh token | Renouveler l'accès en silence | Non | Conservé — rotation ou sender-constraining exigés pour les clients publics | | Implicit | SPA legacy (tokens dans les fragments d'URL) | Oui | **Supprimé** | | Password (ROPC) | L'app collecte elle-même le mot de passe | Oui | **Supprimé** — il ruine tout l'intérêt de la démarche | 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 : | | Access token (OAuth) | ID token (OIDC) | | --- | --- | --- | | Adressé à | Le resource server (API) | **Votre app** (`aud` = votre client ID) | | Prouve | Ce porteur peut accéder à ces scopes | Cet utilisateur (`sub`) s'est authentifié chez cet émetteur (`iss`), maintenant (`iat`/`exp`), pour cette connexion (`nonce`) | | Format | Souvent opaque pour le client | [JWT](/glossary/fr/json-web-token-jwt/) signé que votre app doit valider | | Utilisable pour se connecter ? | **Non** — toute app autorisée par l'utilisateur en détient un ; il ne dit rien de qui est présent | Oui — c'est exactement son métier | "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](https://openid.net/specs/openid-connect-core-1_0.html) 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 `ada@example.com`. 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 | Votre situation | Penchez vers | | --- | --- | | App grand public, audience très mobile | Oui — 2 à 3 fournisseurs + alternative par e-mail | | App iOS proposant une connexion tierce | Une option de connexion respectueuse de la vie privée est obligatoire — prévoyez les e-mails de relais | | Produit B2B/entreprise | OIDC oui, mais vers le [SSO](/glossary/fr/single-sign-on-sso/) d'entreprise, pas le social | | Données réglementées, cycle de vie des comptes strict | Prudence — le blocage chez le fournisseur et la vérification d'identité exigent des réponses | | MVP qui a besoin d'auth cette semaine | Oui, via un backend qui enveloppe les flux | | Utilisateurs sans compte chez les grands fournisseurs | E-mail/passwordless d'abord ; social en option | ## 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](/glossary/fr/listes-de-controle-d-acces-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.