Sécurisez chaque application sans renoncer au contrôle

Aide-moi à ajouter la prise en charge d'OpenID Connect avec FoxIDs à mon application.

Contraintes de périmètre :
- Tu peux utiliser le nom du dossier de workspace comme contexte.
- Ne lis, ne recherches, n'ouvres, n'inspectes et ne déduis rien en dehors du dossier de workspace actuel.
- S'il s'agit d'une nouvelle application, ne passe pas de temps à chercher dans le workspace une implémentation existante. Crée ou génère ce qui est nécessaire dans le dossier de workspace actuel, puis intègre FoxIDs.
- S'il s'agit d'une application existante, n'inspecte que les fichiers situés dans le dossier de workspace actuel.

Avant d'écrire du code, pose les questions requises en exactement deux étapes.

Questions de l'étape 1 :
Pose des questions concises pour déterminer :
- le type d'application
- le langage
- le framework et sa version
- le modèle d'hébergement
- si l'authentification est client-side, server-side ou inconnue
- s'il s'agit d'une nouvelle application ou d'une application existante

Questions de l'étape 2 :
- Pose-les uniquement s'il s'agit d'une application existante.
- Pose des questions concises sur :
  - la méthode d'authentification actuelle
  - l'endroit où les paramètres d'authentification actuels sont configurés
  - l'existence éventuelle d'une UI de login/logout
  - l'existence d'une home page ou d'un layout où des changements minimaux de l'UI d'auth devraient être ajoutés

Règles d'exécution :
- Ne commence pas les changements de code tant que les deux étapes de questions ne sont pas terminées, ou tant que l'étape 1 n'est pas terminée et qu'il est confirmé qu'il s'agit d'une nouvelle application.
- S'il s'agit d'une nouvelle application, passe directement à l'implémentation après l'étape 1. N'effectue pas de recherches exploratoires dont le seul but est de découvrir si des fichiers existent déjà.
- S'il s'agit d'une application existante, n'inspecte que le minimum nécessaire avant d'apporter des modifications.
- Ne pose pas de questions de suivi inutiles si les réponses précédentes suffisent à implémenter correctement l'intégration.

Exigences d'implémentation :
- Ajoute des paramètres pour :
  - `Authority`
  - `ClientId`
- Si l'application est basée sur serveur :
  - ajoute `ClientSecret`
  - utilise un session cookie
  - conserve les tokens sur le serveur
  - PKCE est facultatif
- Si l'application n'est pas basée sur serveur :
  - n'utilise pas `ClientSecret`
  - utilise authorization code flow avec PKCE
- Définis le response type sur `code`
- Définis les scopes pour inclure :
  - `openid`
  - `profile`
  - `email`
- Si c'est pris en charge, définis :
  - Name claim type sur `sub`
  - Role claim type sur `role`
- Utilise les JWT claims dans l'application
- Privilégie l'utilisation d'OpenID Connect Discovery et des informations téléchargées, y compris les clés.
- Privilégie la validation des JWT tokens à l'aide d'OpenID Connect Discovery et des clés téléchargées, et la lecture des claims à partir du JWT token validé
- Seulement si OpenID Connect Discovery et la validation des JWT tokens ne sont pas prises en charge, utilise :
  - user info endpoint: `Authority` + `/oauth/userinfo`
  - authorize endpoint: `Authority` + `/oauth/authorize`
  - token endpoint: `Authority` + `/oauth/token`
- Implémente login et log off
- Ajoute des boutons Log in et Log off
- Après le login, affiche les claims pour le debugging et indique clairement que l'affichage des debug claims devra être supprimé plus tard
- Assure-toi que les données ne sont récupérées et affichées que lorsque l'utilisateur est connecté
- Assure-toi que les données protégées ne sont pas affichées aux utilisateurs anonymes
- S'il existe des APIs, protège-les avec le modèle d'auth de l'application :
  - pour les applications basées sur serveur, protège les APIs avec le session cookie sauf si l'architecture exige spécifiquement des access tokens
  - pour les applications non basées sur serveur, protège les APIs avec un access token
- S'il existe des appels API authentifiés ou des récupérations de données depuis l'UI, assure-toi qu'ils ne s'exécutent que pour les utilisateurs authentifiés

Garde-fous pour une application existante :
- N'introduis pas de refactoring sans rapport
- Ne supprime pas de fonctionnalités existantes sauf si c'est strictement nécessaire pour l'intégration OIDC de FoxIDs
- Garde les changements dans la home page ou le layout minimaux
- Ajoute uniquement ce qui est nécessaire pour :
  - Log in
  - Log off
  - affichage temporaire des debug claims
  - le contrôle de l'affichage des données authentifiées et des fetches protégés
  - la sécurisation des APIs si elles existent

Sortie requise après l'implémentation :
Fournis toujours tout ce qui suit :
- Le domaine de redirection ou la redirect URI exacts à configurer dans FoxIDs
- L'endroit exact où les paramètres sont configurés
- S'il s'agit d'une application existante, la liste des fichiers modifiés
- tous les éventuels pas manuels encore nécessaires, dans l'ordre exact où l'utilisateur doit les effectuer dans FoxIDs et dans l'application
- Une brève explication de la manière d'ajouter et de configurer l'application dans FoxIDs en tant qu'OpenID Connect web application

Niveau de qualité :
- Privilégie l'approche d'authentification native du framework pour le type d'application détecté
- Garde une implémentation minimale et adaptée à la production
- N'ajoute pas de code fictif si une intégration réelle peut être implémentée
- Si quelque chose ne peut pas être réalisé avec le workspace ou l'outillage disponible, indique exactement ce qui bloque et fournis l'étape suivante la plus petite possible