---
tags: Produit, Keycloak
title: Point ADEME keycloak - Territoires en Transitions
---

# Questions

Notice d’installation pas explicite
- Quels genre de notice attendiez-vous ? Il y a eu des points avec Samuel CATHELINE et Arnaud GENRE GRANDPIERRE et les devs
- Une notice dans un format habituel (markdown ou web) et eventuellement avec des examples.
- Il y a eu des points avec Samuel qui nous a aidé notament pour la connexion au VPN

- Auriez-vous préféré plus de détails écrits ?
- Avec des exemples

- Plus de points avec Samuel et Arnaud ?
- Non

- Quelle librairie avez-vous utilisé pour appeler Keycloak ?
- Nous utilisons des requêtes http pour se connecter avec le flow OAuth
- la librarie requests pour les requêtes
- la librarie jwt pour décoder les jetons

Serait-il possible de savoir exactement les difficultés d’intégration que vous avez rencontré ?
- Les différences entre les environements production et de preproduction. Dans l'idéal il faudrait pouvoir se connecter de la même façon, avec le même vpn à ces deux environnements.
- L'impossibilité de valider les jetons JWK avec les librairies standard Python vis a vis des signatures JWKsets
- l'algo utilisé devrait être mentionné
- Beaucoup d'erreurs dans les réponses
- Une centaine de requêtes de verification de jetons non-abouties depuis septembre et nous avons limité nos appels
- Temps de réponse souvent élevé, trop souvent les requêtes aboutissent seulement après plusieurs tentatives
- Nous utilisons le flow OAuth2 d'échange de code, nous ne gérons donc pas de sessions. Les jetons expirant au bout d'une heure seulement nous obligent à les "rafraichir" souvent, les erreurs de rafraichissement pénalisent les utilisateurs qui sont alors déconnectés.

Flow de création de compte pas intuitif (nécessité de demander un mot de passe perdu à la première connexion, nombreux bloquages et sollicitations utilisateurs)
- Parlez-vous bien des utilisateurs de l’application ?
- Oui.
- Quels blocages ont-ils eux en majorité ?
- Difficulté à créer le mot de passe initial avec les règles et le fait de devoir ressaisir à chaque fois qu’on ne respecte pas le règles.
- 1ère connexion après la création de compte car la création de compte ne gère pas directement la création du mot de passe.
- Renvoi de mails dans les spams. Mail qui ne fait pas référence à notre plateforme, (mineur) chartage et contenu vachement dense du mail, pas vraiment convivial
- Si on reste sur la plateforme sans passer par se mails, il faut passer par le même interface que pour la perte de mot de passe donc dire qu’on a perdu son mot de passe ce qui oblige l’utilisateur à dire qu’il a été négligeant ce qui n’est pas vrai

Ergonomie et contenu du mail non spécifique à la plateforme
- Auriez-vous préféré que le mail soit propre à votre application ?
- Oui,
- Si oui, qu’est-ce qui vous gêne le plus dans les mails génériques de Keycloak.
- Pas identifiable directement comme lié au produit depuis lequel les personnes ont fait la demande de mot de passe
- Trop long, trop d’informations dans le mail pas directement utiles pour l’utilisateur.

Nécessité de gérer les données utilisateurs hors keycloak
- Il est actuellement possible de gérer le nom, le prénom, l’email et le mot de passe dans Keycloak. Auriez-vous préféré que d’autres données soient stockées dans Keycloak ? Lesquelles ?
- Pouvoir tout gérer avec des droits admin sur ce qui est commun et spécifique pour notre outil pour les utilisateurs
- Le problème c’est que les données utilisateurs ne seront jamais exactement les mêmes sur toutes les applications.

Repos sur le keycloak pour la connexion (Mode Oauth) - Validité d’une heure seulement des tokens de connexion + problème de disponibilité >> Bugs utilisateurs
- Pourquoi une heure est-ce trop court ? (formulaire énormes à remplir ? …)
- Parce que nous sommes sur un outil de travail d'évaluation qui peut prendre plusieurs heures à remplir, voire jours. Il est possible aujourd'hui de garder des sessions ouvertes de façon plus longue en sécurisant l'authentification du côté client. Les utilisateurs ont l’habitude que leur client reste connecté avec une session ouverte au retour sur le site pour des tas d’applis y compris celles qui gèrent leur carte bleue sans leur redemander leurs codes : ex : Services Google, Service Amazon, service dropbox, etc.
- Est-ce que c’est parce que les utilisateurs de votre application sont souvent inactifs sur votre application ? Par exemple, s’ils ont été déconnectés au retour de la pause déjeuner après deux heures d’inactivité sur l’application c’est normal.
- Normal pour le keycloak dans un objectif de sécurité, mais pas ergonomique et facilitateur de l'usage pour le produit dans l'optique d'un outil de travail qui recherche à faciliter l'usage de la plateforme à son démarrage dans une optique de connexion sur une journée complète de travail et sessions prolongées
Obligation de gérer les sessions nous-même (gère seulement l’authentification). Si keycloak obligation de faire un pont.
- Pouvez être plus précis ? Je ne comprends pas la remarque.
- Idem gestion données utilisateurs hors keycloak

Vous êtes partis sur une autre solution https://github.com/netlify/gotrue qui vous offre plus d’autonomie :
- Est-ce qu’elle vous a permis d’améliorer d’autres points (autre que l’autonomie) ?
- En cours de mise en place
- Est-ce que vous avez points négatifs sur cette solution ?
- Trop tôt pour le dire
- Est-ce qu’une articulation entre Netify et Keycloack parait envisageable et pertinente ? Si oui de quel nature (rôles respectifs) et comment ?
- Basé sur Oauth donc sûrement envisageable