[FEATURE] Rendre le processus d'authentifcation OIDC plus résistant aux retours arrière (PIX-13945)

[lego-technix]

🌸 Problème

Lorsque l’utilisateur s’authentifie auprès d'un SSO OIDC avec succès, il arrive sur la page d’accueil de PIX. Si l’utilisateur décide de cliquer sur le bouton précèdent de son navigateur alors plusieurs cas de figure problématiques peuvent se produire altérant le parcours utilisateur. Des problèmes peuvent aussi survenir lors de ces allers et retours si l’utilisateur fait des CTRL + R.

🌳 Proposition

💡 Lorsque l'utilisateur est déjà authentifié auprès d'un SSO OIDC, passer outre l'authentification OIDC et rediriger l'utilisateur vers la route authenticated (route qui correspond à un utilisateur authentifié). Mais ne pas passer outre la ré-authentification OIDC obligatoire si l'utilisateur participe à une campagne d'une orga associée à un SSO particulier et que l'utilisateur n'est pas authentifié présentement auprès de ce SSO.

ℹ️ Certains SSO refusent qu'on revienne en arrière sur leur page de connexion. Au niveau de Pix on ne peut rien y faire. En fait c'est même la bonne pratique en terme de sécurité. Par contre là où ces SSO pourraient s'améliorer, c'est en ayant alors une page avec une présentation et un texte plus adaptés aux utilisateurs finaux pour mieux expliquer le pourquoi.

🐝 Remarques

C'est uniquement le dernier des commits de cette PR qui met en place la proposition décrite. Tous les commits précédents sont des petits commits de refacto, d'amélioration sur des points rencontrés lors des investigations faites pour mettre en place la proposition de cette PR.

🤧 Pour tester

Tests simples sans campagne

1. Se connecter avec les différents SSO, et avec son navigateur faire des retours arrière et des rechargements de page.
2. Constater que l'utilisateur ne se voit plus présenter de page avec le message Required cookie "state" is missing ou Required "state" is missing in session et que le parcours utilisateur est logique et fluide.

Tests complexes avec campagne

1. Créer une orga liée à un SSO1
2. Créer une campagne pour cette orga
3. Authentifier un utilisateur auprès d'un SSO2
4. Avec cet utilisateur aller à l'URL pour accéder à la campagne de l'orga (l'URL de campagne est de la forme /campagnes/{CODE})
5. Constater que l'utilisateur est obligé de s'authentifier auprès du SSO1 (c'est à dire le SSO1 associé à l'orga)

⚠️ Pour le cas d'utilisation des orgas associées à un SSO particulier, le comportement n'a pas l'air de bien fonctionner tel qu'il est sur dev et tel que déployé en production. Donc si vous trouvez que le fonctionnement que vous rencontrerez dans cette partie est peu satisfaisant, faites les mêmes manipulations sur la recette pour comparer et valider qu'il y a /qu'il n'y a pas de régression.

[pix-bot-github]

Une fois les applications déployées, elles seront accessibles via les liens suivants :

• App (.fr)
• App (.org)
• Orga (.fr)
• Orga (.org)
• Certif (.fr)
• Certif (.org)
• Junior
• Admin
• API
• API MaDDo
• Audit Logger

Les variables d'environnement seront accessibles via les liens suivants :

• scalingo front
• scalingo api
• scalingo api-maddo
• scalingo audit-logger