En juin, on a intégré une couche d’identité aux applications que génère OwlMeans.
L’écran de connexion en était la partie visible. Derrière, il y avait les comptes, les sessions, les permissions, et la séparation entre les personnes qui utilisent notre plateforme et celles qui utilisent l’app d’un client.
Je voulais que ces décisions fassent partie de l’architecture de l’application dès le départ.
Comptes et connexion
Une connexion réussie dit à l’application qui vient d’arriver. Elle ne décide pas de ce que cette personne a le droit de lire ou de modifier.
Un client peut avoir besoin d’un utilisateur qui voit ses propres fiches, d’un opérateur qui traite une file d’attente et d’un administrateur qui gère les accès. Ce sont des responsabilités différentes, même quand les écrans se ressemblent.
La présentation d’OpenID Connect par l’OpenID Foundation décrit le protocole d’identité. Ce sont toujours les règles métier de l’application qui déterminent les permissions.
En juin, on a branché le parcours de connexion sur l’app générée et fourni une manière commune de représenter les accès. Le reste du code disposait ainsi d’une base cohérente sur laquelle s’appuyer.
Ce travail ne fixait pas la politique de chaque client à sa place.
L’implémentation reposait sur des identifiants à usage unique envoyés par e-mail aux utilisateurs finaux de l’app. L’application générée n’avait donc pas besoin d’un parcours à part pour gérer les mots de passe.
Je ne présenterais pas la connexion par e-mail comme une garantie générale de sécurité, et je ne la mettrais pas sur le même plan que les méthodes d’authentification plus fortes.
Il faut encore réfléchir à l’acheminement des e-mails, à la récupération de compte et au comportement des sessions. Et à la façon dont une personne devient membre de l’organisation d’un client.
Ces détails passent facilement à la trappe si le seul critère d’acceptation est que le formulaire de connexion s’envoie.
Les périmètres d’accès
Le modèle de permissions, c’est la partie que je ne voulais pas voir se disperser en décisions prises au cas par cas.
Un écran peut avoir une exigence d’accès, mais l’opération qui se trouve derrière a besoin, elle aussi, d’une exigence réellement appliquée. Masquer un bouton n’est pas une règle d’autorisation.
L’Authorization Cheat Sheet de l’OWASP recommande de définir les périmètres d’accès, de refuser l’accès par défaut et de vérifier les permissions à chaque requête. Elle demande aussi de tester ces règles.
Dans la structure de nos applications, l’exigence se déclare via les conventions d’accès du framework. Le code métier devrait s’y tenir partout, au lieu d’inventer une interprétation différente dans chaque handler.
Pour un outil de travail ordinaire, je testerais les distinctions réelles. Un utilisateur peut consulter sa fiche. Un opérateur peut traiter une demande qui lui est assignée. Ni l’un ni l’autre ne devrait obtenir un accès administrateur du seul fait de s’être connecté.
Ce comportement a sa place dans les exigences du produit et dans les tests. Le nom d’un protocole ne suffit pas à l’établir.
OwlMeans a ses propres comptes. Une app construite avec OwlMeans a ses utilisateurs finaux. Garder ces deux sujets séparés faisait partie du travail sur l’identité.
Les périmètres des clients, des projets et des ressources comptent, parce qu’une identité peut être valide alors qu’une action précise sort de ce qu’elle est autorisée à faire. Un identifiant utilisateur ne suffit pas, à lui seul, à exprimer tous ces périmètres.
La production a aussi besoin de la configuration de connexion qui lui est destinée. Il ne faut pas supposer que les comptes et les adresses de redirection utilisés pendant un aperçu constituent la configuration de production.
En pratique, il s’agit de savoir si la bonne personne peut aller au bout du parcours prévu, et si quelqu’un qui se trouve hors de ce périmètre se voit bien refuser l’accès.
OIDC et livraison
OIDC donne à l’application une interface d’identité standard. Il n’établit pas pour autant que toutes les intégrations d’identité d’entreprise sont disponibles, que chaque cloisonnement entre tenants a été testé, ni qu’on a répondu au questionnaire de sécurité d’un acheteur.
La version précédente de cet article donnait l’impression que tout ça se faisait tout seul.
Une intégration dépend toujours du fournisseur et de la configuration. Les rôles d’un client et les règles de son organisation restent à spécifier. Relire l’application générée reste une étape de la livraison.
Je préfère décrire les briques dont on dispose plutôt que de laisser entendre qu’un choix de protocole vaut certification.
En août, le système d’identité intégré est devenu la seule implémentation de l’IAM de la Plateforme. Ce que la version de juin disait d’un backend externe interchangeable n’a plus qu’une valeur historique.
Le travail en cours sur les accès distingue aussi les contrôles déjà implémentés des améliorations encore en développement. La documentation et le code apportent des éléments de preuve sur le mécanisme. Ils ne peuvent pas établir que chaque application construite avec lui est sûre.
Le guide actuel sur l’authentification explique les briques du framework. Il faut vérifier la conception des accès de l’application dans le contexte du produit qu’on construit.
Intégrer l’identité veut dire qu’on maintient nous-mêmes cette partie du système. Les clients doivent toujours décrire les personnes, les ressources et les actions dont leur produit a besoin. On a une manière commune d’exprimer ces règles. Les vérifier fait encore partie du travail.
Révisé le 15 octobre 2026. Cette version garde le récit de l’implémentation de juin, mais corrige les comparaisons de prix de la version précédente et ses promesses trop larges sur l’usage en entreprise et la sécurité.