Cliquez sur le lien SSO fourni par le service partenaire. Ce lien contient généralement un paramètre nommé session_token (ou équivalent) et éventuellement redirect_url, domain ou hide_menu.

Confirmez que l’URL affiche bien le paramètre token. Si aucun token n’est présent : redirigez l’utilisateur vers la page de connexion classique et demandez au partenaire de renvoyer le lien SSO.

Traitez ce lien comme sensible. Ne le copiez pas dans des espaces publics (chat, forums, e‑mail) : toute personne ayant le lien pourrait tenter d’ouvrir la session.

Si vous copiez le token manuellement, éliminez les espaces invisibles ou caractères non imprimables (parfois générés lors d’un encodage/décodage). Un token corrompu provoquera un rejet immédiat.

Si le flux échoue en environnement normal, testez dans une fenêtre privée : cela permet de vérifier l’impact du cache, des cookies et des extensions.

Assurez-vous que le lien provient du partenaire attendu (adresse ou mail). Si le lien comporte un paramètre domain, confirmez qu’il correspond au domaine cible ou à un domaine de confiance.

Contrôlez redirect_url : n’autorisez la redirection que vers des chemins internes connus. Évitez les redirections vers des sites externes non vérifiés.

Faites une vérification de surface : le token doit ressembler à une chaîne compacte (pas d’espaces, pas de caractères étranges). Si la structure semble incohérente, refusez la consommation et demandez un nouveau lien.

Si le lien ou les informations associées indiquent une durée de vie, vérifiez qu’elle n’est pas dépassée. Lors d’un doute, demandez un nouveau lien.

Considérez chaque token comme à usage unique : si vous pensez qu’il a déjà servi, refusez la tentative et demandez une réémission.

Avant d’appliquer un nouveau token, effacez les données d’authentification précédentes stockées localement (si l’interface le propose). Cela évite les conflits entre sessions.

• Si l’ouverture se fait dans une iframe, conservez le token de façon temporaire accessible à la page enfant (ex. stockage temporaire accessible uniquement pour la session en cours).
• Si l’ouverture se fait dans une fenêtre normale, préférez le stockage via un mécanisme sécurisé qui ne persistera pas inutilement.

Lorsque le flux est autorisé, créez une cookie de session sécurisé et à portée correcte du domaine (avec flags de sécurité activés) pour que la session soit reconnue sur les pages suivantes.

Demandez au système de récupérer les données utilisateur liées au token et d’initialiser la session. Affichez à l’utilisateur un message clair (“Connexion en cours…”) pendant l’opération.

Une fois la session établie, redirigez l’utilisateur vers la page demandée (redirect_url) ou vers l’accueil de l’application si rien n’est précisé.

Après création de la session, supprimez toute copie du token stockée temporairement pour éviter toute fuite ultérieure.

Affichez un message simple : “Lien SSO invalide ou manquant. Veuillez vous connecter manuellement ou demander un nouveau lien.” Proposez un bouton pour la page de connexion classique.

Indiquez clairement que le lien a expiré et fournissez une action : demander un nouveau lien ou renvoyer l’e‑mail d’invitation.

Empêchez la redirection vers des destinations inconnues et affichez une alerte expliquant pourquoi (sécurité). Offrez la possibilité de revenir à l’interface principale.

Pour chaque refus (token invalide, expired, redirection non autorisée), enregistrez un message d’erreur lisible pour l’équipe support afin de faciliter le diagnostic.

Proposez un lien vers le support ou un guide d’aide, et précisez le moment où l’utilisateur peut réessayer (par exemple, “Demander un nouveau lien”).