Qu'est-ce que le 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

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 :

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

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

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

SP-initiated vs. IdP-initiated

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 spécifie les deux profils ; la règle pratique est dans la dernière ligne du tableau.

SAML vs. OIDC

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

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