Authentification unique (SSO)

Toutes les applications Inklura (la console, SMS Designer, SEO, Mail, la caisse, le support) partagent une même connexion. Le SSO repose sur deux mécanismes :

  1. OpenID Connect avec PKCE : chaque application authentifie l'utilisateur auprès du fournisseur d'identité commun, et la session ouverte chez ce fournisseur rend les connexions suivantes transparentes.
  2. Un passage de session depuis la console : pour ouvrir une application sœur à un utilisateur déjà connecté à la console, sans nouvelle connexion (utilisé pour l'embarquement en iframe).

Pour l'authentification en général (cookies de session, JWT Bearer, liens d'invitation), voir Authentification.

OpenID Connect avec PKCE

Le fournisseur d'identité est auth.1clic.pro. Chaque application y est enregistrée comme client OIDC et connecte les utilisateurs par le flux par code d'autorisation avec PKCE (S256). Les applications outils (SMS Designer, Mail Designer, SEO…) sont des clients publics, sans secret client, et demandent les scopes openid profile email offline_access.

Un cookie de session par application

Au retour du fournisseur d'identité, chaque application crée son propre cookie de session, limité à son hôte. Le cookie n'a pas d'attribut Domain : il n'est pas partagé entre sous-domaines.

Pourquoi l'utilisateur reste connecté d'une application à l'autre

Ce n'est pas un cookie commun qui donne cette impression. Ce qui est partagé, c'est la session ouverte chez auth.1clic.pro. Quand un utilisateur déjà connecté arrive sur une deuxième application, l'aller-retour OIDC de cette application aboutit sans saisie de mot de passe, et l'application crée son cookie local.

application B : pas de cookie local ──> redirection vers auth.1clic.pro
                session déjà ouverte ──> autorisation immédiate ──> /auth/callback
                application B crée SON cookie de session

Passage de session depuis la console

Pour ouvrir une application sœur à un utilisateur déjà connecté à la console (par exemple dans une iframe), la console émet un jeton signé de courte durée et redirige le navigateur vers l'application cible. L'application vérifie le jeton et ouvre sa propre session.

Le jeton :

  • porte uniquement l'identité de l'utilisateur connecté (nom, e-mail, organisation) et le site sélectionné dans la console : on ne peut pas s'en servir pour agir au nom de quelqu'un d'autre ;
  • est adressé à l'application cible, qui le vérifie avant de l'accepter ;
  • expire au bout de deux minutes.

La route de lancement

GET https://manage.inklura.fr/api/manage/designer-sso?app=<clé>&next=<chemin>&embed=1
Paramètre Rôle
app L'application à ouvrir, par ex. mail, sms, seo, support, pos
next Le chemin où atterrir dans l'application (un chemin local, tronqué à 512 caractères ; /manage par défaut ou si la valeur n'est pas un chemin local)
embed 1 quand l'application est affichée dans une iframe de la console

La route exige une session console : sans session, le navigateur est renvoyé vers la page de connexion de la console, et une valeur app inconnue redirige vers /manage. Sinon, elle redirige vers l'application cible, qui vérifie le jeton, ouvre sa session et redirige vers next.

console (connectée) ──GET /api/manage/designer-sso?app=mail&next=/manage&embed=1
   jeton émis pour l'application mail (valable deux minutes)
   302 ──> maildesigner.inklura.fr, qui vérifie le jeton
      session ouverte ──> 302 /manage

Même site ou nouvel onglet

Les applications servies sur le domaine de la console (*.inklura.fr), comme Mail, SMS, SEO, le support et la caisse, s'affichent dans une iframe. Celles qui vivent sur un autre domaine s'ouvrent dans un nouvel onglet, car une iframe d'un autre site ne reçoit pas leur cookie de session. La règle a des exceptions dans les deux sens : une application d'un autre domaine peut s'afficher en iframe si elle pose un cookie partitionné, et certaines applications s'ouvrent dans un nouvel onglet bien qu'elles soient sur inklura.fr. Voir Embarquement en iframe.

Voir aussi