Capturer des tableaux de bord protégés par un SSO

Pourquoi les tableaux de bord SSO résistent aux API de capture simples

La plupart des API de capture partent d’une URL publique : vous transmettez un lien, le service charge la page une fois, et vous recevez un PNG. Ce modèle s’effondre dès que la cible se trouve derrière un fédéré d’identité (SSO). Les consoles d’analyse, les portails RH et les outils BI internes exposent rarement un instantané HTML stable sans authentification. Le navigateur enchaîne plutôt des redirections — souvent SAML 2.0, OpenID Connect et cookies de session — avant qu’un graphique ou un tableau n’apparaisse.

L’automatisation sans tête qui se contente d’un unique GET bute donc sur un mur de connexion, un challenge IdP ou un interstitiel de consentement. Pour obtenir le rendu réel d’un utilisateur, il faut soit rejouer fidèlement cette séquence de navigation, soit injecter des identifiants déjà reconnus par l’IdP (cookies ou jetons portés par le contexte navigateur).

Interaction entre SAML, OIDC et automatisation

Dans un flux SAML, le fournisseur de service redirige vers l’IdP ; l’utilisateur s’authentifie ; l’IdP renvoie une assertion ; le SP établit une session. Les variantes OIDC conservent la même idée : l’état transite par des redirections et des POST de formulaire, pas par un appel REST que votre backend pourrait imiter sans effort.

D’où l’échec du simple « télécharge l’URL du tableau de bord ». Le moteur de capture doit exécuter le même graphe de navigation qu’un humain : suivre les redirections, soumettre les formulaires nécessaires, attendre la stabilité du DOM après chaque saut, puis déclencher la capture.

Enchaîner les étapes pour parcourir la connexion complète

Les étapes d’automatisation permettent de scripter ce parcours dans un vrai navigateur : ouvrir l’URL de départ, cliquer sur « Se connecter avec le SSO », attendre la page IdP, saisir des identifiants si votre politique l’autorise (ou marquer une pause sur un sélecteur connu après validation externe), puis poursuivre jusqu’à ce que le socle du tableau de bord soit interactif. Les étapes s’exécutent dans l’ordre, comme avec Playwright ou Puppeteer — sans que vous gériez la flotte.

En pratique : un wait après chaque redirection jusqu’à l’apparition d’un sélecteur connu ; une étape navigate si l’IdP renvoie une URL intermédiaire ; un scroll avant capture lorsque les graphiques se chargent en différé. Combinez avec le routage par pays si votre politique SSO varie selon la région.

Quand les cookies restent le meilleur choix en entreprise

Dans de nombreux environnements réglementés, stocker des mots de passe dans l’automatisation est inacceptable. Une approche plus propre consiste à obtenir un cookie de session (ou un jeu d’en-têtes) depuis votre propre sous-système de confiance — après authentification réelle de l’utilisateur — puis à le transmettre à l’API de capture pour que le worker charge le tableau de bord déjà authentifié.

Vous évitez ainsi de rejouer l’IdP à chaque capture, vous ménagez votre infrastructure d’identité et vous tenez les secrets hors des définitions d’étapes. En contrepartie, il faut renouveler les cookies avant expiration et garantir que le jar correspond aux règles de domaine et de chemin de la production.

Comparaison des approches

Approche	Idéal pour	Compromis
Automatisation complète via SSO	Tests de bout en bout, intégrations neuves	Plus d’étapes ; sensibilité aux changements d’UI IdP ; MFA bloquante
Cookies pré-authentifiés	Surveillance planifiée d’outils internes	Rotation des cookies ; alignement domaine / chemin
Hybride (étapes + en-têtes)	SSO puis validation MFA hors bande	Points de reprise et timeouts à clarifier

Exemple cURL avec cookies après échange côté backend

curl -G "https://api.screenshotcenter.com/api/screenshot/create" \
  --data-urlencode "url=https://analytics.internal.example.com/overview" \
  --data-urlencode "key=VOTRE_CLE_API" \
  --data-urlencode "cookies=session=eyJhbGciOiJIUzI1NiJ9...; Path=/; Secure; HttpOnly"

Encodez l’URL pour les points-virgules et espaces lorsque la chaîne de cookies transite en paramètre de requête.

Exemple JavaScript avec étapes d’automatisation

const res = await fetch("https://api.screenshotcenter.com/api/screenshot/create", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "X-API-KEY": process.env.SCREENSHOTCENTER_API_KEY,
  },
  body: JSON.stringify({
    url: "https://app.example.com/login",
    steps: [
      { action: "click", selector: "button[data-provider='okta']" },
      { action: "wait", duration: 2000 },
      { action: "type", selector: "#okta-signin-username", text: process.env.OKTA_USER },
      { action: "type", selector: "#okta-signin-password", text: process.env.OKTA_PASS },
      { action: "click", selector: "input[type='submit']" },
      { action: "wait", selector: "[data-dashboard='ready']", timeout: 60000 },
    ],
    delay: 1500,
  }),
});
const json = await res.json();

Ne commitez jamais de vrais identifiants ; injectez-les depuis un coffre de secrets à l’exécution. En production, privilégiez les comptes de service uniquement là où la sécurité l’autorise explicitement.

Cadre opérationnel pour les équipes sécurité

Documentez les domaines qui reçoivent des cookies, les étapes qui touchent l’IdP et la durée de vie des sessions. Limitez le débit des jobs qui rejouent une connexion complète pour ne pas déclencher de politiques anti-bruteforce. Si l’IdP impose la posture de poste ou un score de risque, le navigateur sans tête peut être challengé : prévoyez l’injection manuelle de cookies ou un compte de supervision au RBAC restreint.

Nouvelles tentatives, idempotence et observabilité

Les flux SSO échouent parfois lorsque l’IdP renvoie une page d’erreur passagère ou qu’un équilibreur affiche une bannière de maintenance. Traitez les jobs de capture comme tout travail distribué : appliquez des nouvelles tentatives bornées avec jitter, enregistrez l’URL finale après redirection pour le diagnostic (en masquant les cookies dans les journaux) et alertez l’astreinte lorsque les échecs se concentrent sur un même locataire. Si des étapes saisissent un mot de passe, séparez les pistes d’audit des traces brutes d’étapes afin de reconstituer la chronologie sans exposer d’identifiants en clair.

Poursuivre la lecture

Pour une vue d’ensemble sur les captures authentifiées — lots, stockage, remises — consultez Captures derrière la connexion. La sémantique des étapes, les sélecteurs et les timeouts sont détaillés dans Étapes d’automatisation.