--- term: 'Single Sign-On (SSO)' seoTitle: 'Single Sign-On (SSO) : fonctionnement, SAML vs. OIDC, risques' headline: "Qu'est-ce que le Single Sign-On (SSO) ?" slug: single-sign-on-sso category: auth-security shortDefinition: "Le single sign-on est une méthode d'authentification où une seule connexion chez un fournisseur d'identité ouvre l'accès à de nombreuses applications." relatedTerms: - identity-access-management-iam - oauth-2-social-login - multi-factor-authentication-mfa - session-management contrastsWith: - oauth-2-social-login aboutTerms: - 'Identity Provider (IdP)' - 'Service Provider (SP)' - 'SAML' - 'Single Logout (SLO)' faq: - question: "Qu'est-ce que le SSO en termes simples ?" answer: "Une seule connexion déverrouille de nombreuses apps : vous prouvez une fois qui vous êtes auprès d'un fournisseur d'identité central, et chaque application connectée fait confiance à cette preuve au lieu de réclamer son propre mot de passe. La connexion du matin au portail de l'entreprise, qui ouvre en silence la messagerie, le wiki et le CRM, c'est le SSO à l'œuvre." - question: 'Comment fonctionne le SSO ?' answer: "Par redirections et tokens signés. L'app envoie l'utilisateur non authentifié vers le fournisseur d'identité ; l'utilisateur s'y authentifie — mot de passe plus MFA — et l'IdP émet une assertion signée numériquement que le navigateur rapporte ; l'app valide la signature contre des certificats échangés à l'avance et démarre une session. L'app suivante saute l'étape de connexion parce que la session IdP existe déjà." - question: 'Le SSO est-il sûr ?' answer: "Le bilan est positif quand le fournisseur d'identité impose la MFA : il existe moins de mots de passe à hameçonner, et la politique, l'audit et le blocage vivent au même endroit. La contrepartie honnête, c'est la concentration — un seul compte IdP compromis, ou l'IdP lui-même, ouvre tout ce qui se trouve en aval. Le SSO rend la porte d'entrée excellente et unique." - question: 'Quelle est la différence entre le SSO et un gestionnaire de mots de passe ?' answer: "Un gestionnaire de mots de passe stocke de nombreux secrets et les saisit à votre place — chaque app garde sa propre connexion. Le SSO supprime purement et simplement les mots de passe par app : les apps délèguent l'authentification à l'IdP et ne détiennent aucun identifiant vous concernant. Les deux se complètent ; les gestionnaires couvrent la longue traîne des apps sans support SSO." - question: "La connexion sociale, est-ce la même chose que le SSO ?" answer: "Même machinerie, propriétaire différent. Les deux sont des flux de redirection de style OIDC vers un fournisseur d'identité — mais la connexion sociale utilise l'IdP d'une plateforme grand public pour entrer dans une seule app, tandis que le SSO d'entreprise utilise un IdP contrôlé par l'organisation, dont la session unique couvre toute une suite d'applications." - question: 'SAML ou OIDC pour le SSO ?' answer: "OIDC pour tout ce qui est neuf — du JSON et des JWT sur REST, à l'aise avec le mobile et les SPA, plus simple à implémenter et à déboguer. SAML pour la compatibilité — le protocole de l'ère XML, solidement installé dans les fournisseurs d'identité d'entreprise. Les produits qui vendent aux grands comptes finissent en général par parler les deux." - question: 'Faut-il encore de la MFA avec le SSO ?' answer: "Absolument — le SSO rend cette connexion unique plus précieuse, pas moins. La vertu compensatoire : imposer la MFA au niveau du fournisseur d'identité protège toutes les applications connectées d'un seul geste, ce qui est précisément la centralisation que le SSO existe pour offrir." - question: "Que se passe-t-il quand le fournisseur d'identité est en panne ?" answer: "Plus personne ne démarre de nouvelle session dans une app connectée — les sessions applicatives en cours survivent jusqu'à leur expiration. C'est le visage disponibilité du point de défaillance unique, et la raison pour laquelle la redondance de l'IdP, les comptes d'administration de secours et les chemins de repli appartiennent au plan de déploiement, pas au post-mortem." codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'SAML 2.0 Technical Overview — OASIS' url: 'https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html' - name: 'OpenID Connect Core 1.0' url: 'https://openid.net/specs/openid-connect-core-1_0.html' - name: 'NIST SP 800-63C — Federation and Assertions' url: 'https://pages.nist.gov/800-63-4/sp800-63c.html' - name: 'RFC 6749 — The OAuth 2.0 Authorization Framework' url: 'https://datatracker.ietf.org/doc/html/rfc6749' cta: title: "La connexion d'entreprise, à un adaptateur de distance" text: "Pointez les adaptateurs d'authentification de Back4app vers le fournisseur d'identité de votre client — Keycloak, LDAP ou n'importe quel émetteur OIDC — et Back4app vérifie ses tokens côté serveur, mappe les identités sur vos utilisateurs et émet les sessions de votre app." linkText: 'Commencez gratuitement' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-10' translationKey: single-sign-on-sso --- **Le single sign-on est une méthode d'authentification où une seule connexion chez un fournisseur d'identité ouvre l'accès à de nombreuses applications.** La distribution tient en deux rôles : le **fournisseur d'identité (IdP)** authentifie les utilisateurs et se porte garant d'eux ; chaque **service provider (SP)** — les apps que vous voulez réellement utiliser — fait confiance à cette garantie au lieu de faire tourner sa propre connexion. Une distinction pédante mérite d'être gardée : des apps qui partagent un annuaire mais redemandent chacune le mot de passe font du *same* sign-on ; le vrai SSO signifie qu'on ne vous le demande qu'une seule fois. ## Points clés | Question | Réponse | | --- | --- | | La distribution | L'IdP authentifie et se porte garant · les SP font confiance à cette garantie | | Le mécanisme | Redirections + assertions signées — le mot de passe ne quitte jamais l'IdP | | Les protocoles | SAML (XML, legacy d'entreprise) · OIDC (JWT sur OAuth, le choix par défaut moderne) | | Le compromis | Une porte d'entrée excellente — et une seule porte qui vaut tout ce qu'il y a derrière | | Les petites lignes | La déconnexion unique est difficile · les sessions tournent sur plusieurs horloges · le SSO coûte un supplément en SaaS | ## La danse des redirections, étape par étape Pourquoi des redirections ? À cause de la politique de même origine du navigateur : `app.example.com` ne peut pas lire un cookie de connexion appartenant à `idp.example.org`, donc l'identité doit voyager *sous forme de message signé à travers le navigateur* plutôt que de cookie partagé — et c'est exactement ce que fait le flux : ```text 1 L'utilisateur ouvre app.example.com — aucune session 2 Le SP redirige vers l'IdP avec une requête d'authentification 3 L'utilisateur s'authentifie CHEZ L'IDP (mot de passe + MFA) — ou possède déjà une session IdP, et cette étape est silencieusement sautée 4 L'IdP émet une assertion signée (XML SAML) ou un ID token (JWT OIDC) 5 Le navigateur la livre à l'URL de callback du SP 6 Le SP valide : signature · émetteur · audience · expiration · rejeu 7 Le SP démarre sa propre session locale — l'utilisateur est entré 8 App suivante : étapes 1–2, puis droit du chemin silencieux de 3 vers 7 ``` Voilà à quoi ressemble le côté service provider quand un backend l'enveloppe : **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // Enterprise SSO: the IdP authenticates; the app trusts its signed token // After the OIDC redirect dance, the client holds the IdP's tokens: const user = await Parse.User.logInWith('keycloak', { authData: { id: subClaim, // the IdP's stable subject ID access_token: accessToken, // verified server-side against the IdP }, }); // One IdP login now serves every app that trusts the same issuer. ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // Enterprise SSO: the IdP authenticates; the app trusts its signed token // After the OIDC redirect dance, the client holds the IdP's tokens: final user = ParseUser.forQuery(); final response = await user.loginWith('keycloak', { 'id': subClaim, // the IdP's stable subject ID 'access_token': accessToken, // verified server-side against the IdP }); // One IdP login now serves every app that trusts the same issuer. ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // Enterprise SSO: the IdP authenticates; the app trusts its signed token // After the OIDC redirect dance, the client holds the IdP's tokens: let user = try await User.loginWith( "keycloak", authData: [ "id": subClaim, // the IdP's stable subject ID "access_token": accessToken // verified server-side against the IdP ] ) // One IdP login now serves every app that trusts the same issuer. ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // Enterprise SSO: the IdP authenticates; the app trusts its signed token // After the OIDC redirect dance, the client holds the IdP's tokens: val authData = mapOf( "id" to subClaim, // the IdP's stable subject ID "access_token" to accessToken // verified server-side against the IdP ) ParseUser.logInWithInBackground("keycloak", authData).continueWith { task -> val user = task.result // One IdP login now serves every app that trusts the same issuer. } ``` ```mermaid flowchart LR accTitle: Flux de single sign-on entre les service providers et le fournisseur d'identité accDescr: Un utilisateur non authentifié sur un service provider est redirigé vers le fournisseur d'identité, s'authentifie une fois avec MFA et reçoit une assertion signée livrée au service provider, qui la valide et démarre une session locale. Une seconde application répète la redirection, mais la session existante du fournisseur d'identité rend la connexion silencieuse. U["Utilisateur"] --> SP1["App A (SP)
aucune session"] SP1 -->|"redirection + requête d'auth"| IDP["Fournisseur d'identité
connexion + MFA · session globale"] IDP -->|"assertion signée"| SP1 SP1 -->|"validation → session locale"| OK1["App A ouverte"] U2["Même utilisateur, plus tard"] --> SP2["App B (SP)"] SP2 -->|"redirection"| IDP IDP -.->|"session existante —
assertion silencieuse"| SP2 --> OK2["App B ouverte,
aucune connexion affichée"] ``` ## SP-initiated vs. IdP-initiated | | SP-initiated | IdP-initiated | | --- | --- | --- | | Démarre depuis | L'app ("Se connecter en SSO") | La tuile du dashboard de l'IdP | | Requête | Le SP émet une requête d'authentification | Aucune — l'assertion arrive non sollicitée | | Liaison de la réponse | L'assertion répond à une requête précise | Aucune requête à laquelle la rattacher | | Posture de sécurité | Le choix par défaut — les contrôles anti-rejeu s'ancrent sur la requête | Historiquement plus faible ; les assertions non sollicitées invitent l'injection | | Le supporter ? | Toujours | Seulement là où l'IdP l'exige, avec une validation supplémentaire | La plupart des explications ne décrivent que le premier et ne nomment jamais le second — or les IdP d'entreprise adorent les tuiles de dashboard, donc les SP rencontrent les deux. La [vue d'ensemble technique de SAML](https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html) spécifie les deux profils ; la règle pratique est dans la dernière ligne du tableau. ## SAML vs. OIDC | | SAML 2.0 | OpenID Connect | | --- | --- | --- | | Époque et format | 2005 · assertions XML | 2014 · [JWT](/glossary/fr/json-web-token-jwt/) sur [OAuth 2.0](/glossary/fr/oauth-2-connexion-sociale/) | | Transport | Bindings POST/redirect du navigateur | REST + redirections | | Convient à | Applications web d'entreprise, IdP legacy | Mobile, SPA, API — tout ce qui est actuel | | Expérience développeur | Verbeuse, fragile, dépendante des bibliothèques | Tokens lisibles, flux standards | | Verdict | Supportez-le parce que les IdP de vos clients le parlent | Choisissez-le pour tout ce qui est neuf | Et le triangle qui démêle les acronymes, une bonne fois : **SAML et OIDC font l'authentification pour le SSO ; [OAuth 2.0 seul fait de l'autorisation](/glossary/fr/authentification-vs-autorisation/)** — OIDC est la couche d'identité qui a rendu la plomberie d'OAuth sûre pour la connexion. La connexion sociale, c'est la même machinerie OIDC avec une plateforme grand public comme IdP et une seule app comme audience ; le SSO d'entreprise change de propriétaire et élargit la session à toute une suite. ## Ce dont personne ne parle **La déconnexion unique (SLO) est la moitié difficile.** La connexion converge *vers* un seul IdP ; la déconnexion doit diverger *vers* chaque SP qui détient une session locale — et la chaîne casse si une app ne répond pas, les restrictions des navigateurs sur les cookies tiers cassent les notifications front-channel, et rien n'atteint vos autres appareils. En pratique, "déconnecté partout" veut dire des sessions locales courtes qui revérifient la session IdP (terminée), pas une diffusion fiable. **Les sessions tournent sur trois horloges :** la session globale de l'IdP, la [session](/glossary/fr/gestion-des-sessions/) locale de chaque app, et la fenêtre de validité de l'assertion elle-même. Se déconnecter d'une app pendant que la session IdP vit signifie une réentrée silencieuse à la visite suivante — un comportement que les utilisateurs signalent comme un bug et que les architectes devraient reconnaître comme la conception. **Et la taxe SSO :** les éditeurs SaaS placent régulièrement le support SAML/SSO derrière des paliers entreprise à plusieurs fois le pricing de base — un fait de marché à budgéter, puisque l'exigence de l'équipe sécurité et la ligne d'achat arrivent ensemble. ## Le rayon d'impact, honnêtement Le SSO concentre le risque exprès — c'est ce que "single" veut dire. Un seul compte IdP compromis ouvre toutes les apps connectées ; un IdP *lui-même* compromis — y compris le vol de ses clés de signature d'assertions, le pattern d'attaque dit de la "golden assertion" — fabrique une identité valide pour n'importe qui, partout. Les éditeurs adoucissent le tableau ; la réponse d'ingénierie consiste à dépenser cette concentration intelligemment : **une [MFA](/glossary/fr/authentification-multifacteur-mfa/) résistante à l'hameçonnage au niveau de l'IdP** (cette connexion unique mérite désormais une protection de niveau passkey), une **authentification renforcée** pour les apps sensibles plutôt qu'une session globale valable pour tout, des **sessions globales courtes** là où les enjeux sont élevés, la rotation et la supervision des clés de signature, et des comptes locaux de secours pour le jour où l'IdP tombe. Le point de défaillance unique ne disparaît jamais — on le blinde, parce que blinder un seul point est exactement l'économie que le SSO promettait. ## S'intégrer en tant que service provider Ce que "nous supportons le SSO" exige réellement d'une équipe applicative, en une liste : enregistrer votre URL de callback/ACS auprès de l'IdP et échanger les métadonnées (émetteur, certificats) ; tout valider sur chaque assertion — signature, émetteur, audience, expiration et liaison anti-rejeu ; mapper les claims de l'IdP sur votre modèle utilisateur, indexé sur le subject stable, jamais sur l'e-mail seul ; provisionner à la volée (la première connexion SSO crée l'utilisateur local) ; traiter délibérément les arrivées IdP-initiated ; et confronter les attentes de déconnexion à la réalité des trois horloges ci-dessus. Le chemin est balisé — c'est pour cela que des IdP open-source comme Keycloak existent de l'autre côté de la poignée de main — mais chaque point sauté est un constat de sécurité assorti d'une échéance. ## Cas d'usage courants - **Suites applicatives internes** — le cas canonique : une connexion le matin, tous les outils internes et SaaS ensuite. - **SaaS B2B qui monte en gamme** — "supporte le SSO" comme case à cocher qui conditionne le deal entreprise. - **Éducation et santé** — accès fédéré entre institutions, là où les racines de SAML sont les plus profondes. - **MFA et offboarding centralisés** — un seul endroit pour imposer les facteurs ; un seul interrupteur qui met fin partout à l'accès d'un employé parti. - **Produits multi-apps** — votre propre suite partageant une connexion via votre propre IdP, à la manière grand public. ## Devriez-vous ajouter le SSO ? Matrice de décision | Situation | Penchez vers | | --- | --- | | Vous vendez aux grands comptes | Oui — OIDC + SAML ; cela conditionne les deals | | Outils internes derrière un IdP d'entreprise unique | Oui — centralisez la MFA et l'offboarding | | App grand public | [Connexion sociale](/glossary/fr/oauth-2-connexion-sociale/) — même machinerie, IdP grand public | | Une seule app, petite équipe | Sessions + MFA suffisent ; reposez la question à la troisième app | | Apps à forte assurance derrière le SSO | Ajoutez une authentification renforcée — ne vous reposez pas sur la session globale | | Choix d'un protocole aujourd'hui | OIDC d'abord ; SAML pour les clients qui l'exigent | ## Limites et trade-offs - **La disponibilité se concentre avec l'identité.** L'indisponibilité de l'IdP est la panne de connexion de tout le monde ; redondance et chemins de secours font partie de la feature, ce ne sont pas des ajouts. - **La déconnexion est plus faible que la connexion.** La divergence du SLO échoue partiellement par conception ; ce sont des sessions locales courtes, et non des diffusions de déconnexion, qui apportent la vraie garantie. - **La longue traîne reste sous mot de passe.** Les apps sans support SSO gardent leurs propres identifiants — les gestionnaires de mots de passe restent la couche de ramassage. - **L'empilement des sessions déroute les utilisateurs.** La reconnexion silencieuse et les tickets "je me suis déconnecté mais non" sont la facture UX de la conception à trois horloges ; la documentation et des timeouts prévisibles la remboursent. - **La qualité d'intégration varie d'un SP à l'autre.** Le plafond de sécurité du SSO est fixé par la validation d'assertion la plus négligée parmi vos apps connectées — la checklist ci-dessus est par app, pour toujours. ## Le SSO 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. Une app rejoint ici un domaine SSO en tant que service provider par le même mécanisme d'adaptateurs qui alimente la [connexion sociale](/glossary/fr/oauth-2-connexion-sociale/) : Back4app livre des adaptateurs d'authentification pour Keycloak, LDAP et les émetteurs OAuth2/OIDC génériques, si bien que le flux des onglets de code — l'IdP authentifie, l'app reçoit les tokens, `logInWith` les vérifie côté serveur auprès de l'émetteur — transforme le SSO d'entreprise en configuration plus un handler de redirection. Les identités s'indexent sur le subject stable de l'IdP dans des blocs `authData` par fournisseur, la première connexion provisionne l'utilisateur à la volée, `linkWith` rattache des méthodes supplémentaires pour le chemin de secours, et la session que votre app émet reste une session Parse révocable — l'empilement à trois horloges se termine donc, de votre côté, par une horloge que vous contrôlez entièrement.