Dès qu'une PME dépasse une dizaine d'utilisateurs, la question n'est plus « quel mot de passe » mais « où vit l'identité ». Et dès qu'une application tierce doit lire des données d'Odoo, la question devient « avec quel jeton ».
Treize modules communautaires répondent aux deux — et terminent le dépôt server-auth.
Résumé
Cinq modules traitent l'authentification unique : un connecteur SAML2, quatre extensions du mécanisme OAuth — fournisseurs filtrés par domaine de connexion, login distinct de l'adresse à la création d'un compte, sessions simultanées sur plusieurs appareils —, et le placement des identifiants OIDC dans un fichier serveur.
Un module étend l'annuaire LDAP : la correspondance explicite de l'attribut utilisé pour le nom et l'adresse à la création d'un utilisateur.
Quatre modules traitent l'accès programmatique : le regroupement des clés d'API, le placement de leur valeur réelle dans un fichier serveur, l'authentification par jeton JWT dans l'en-tête des requêtes avec ses validateurs, et son module de démonstration.
Trois modules enfin traitent les accès particuliers : la connexion croisée d'une instance Odoo vers une autre — un module client, un module serveur —, et un groupe de sécurité isolé de sous-traitant simulant un utilisateur interne au minimum de permissions.
L'essentiel
- L'authentification unique SAML2, avec un fournisseur d'identité externe.
- Les fournisseurs OAuth filtrés par domaine de connexion.
- Des sessions OAuth simultanées sur plusieurs appareils.
- Les identifiants OIDC hors base, dans un fichier serveur.
- Des clés d'API groupées, et leur valeur hors base.
- L'authentification par jeton JWT sur les routes, avec validateurs.
- La connexion croisée d'une instance Odoo vers une autre.
- Un groupe sous-traitant au minimum de permissions.
Ce que ces modules ajoutent à l'instance
| Famille | Modules | Nombre |
|---|---|---|
| Authentification unique | auth_saml, auth_oauth_filter_by_domain, auth_oauth_login_field, auth_oauth_multi_token, auth_oidc_environment | 5 |
| Annuaire | users_ldap_mail | 1 |
| Accès programmatique | auth_api_key_group, auth_api_key_server_env, auth_jwt, auth_jwt_demo | 4 |
| Accès particuliers | cross_connect_client, cross_connect_server, base_group_subcontractor | 3 |
Les menus : Paramètres ▸ Utilisateurs & Sociétés ▸ JWT Validators, Paramètres ▸ Technique ▸ Auth Api Key Groups et Cross Connect ▸ Cross Connect Servers.
L'authentification unique
Déporter l'identité vers un annuaire d'entreprise change la nature de l'administration : le départ d'un salarié se traite une fois, dans l'annuaire, et non dans chaque application. C'est aussi ce qui permet d'imposer un double facteur partout en une décision.
auth_saml (version 18.0.1.1.3) connecte Odoo à un fournisseur d'identité SAML2 — le protocole d'authentification unique le plus répandu en entreprise.
Quatre modules étendent le mécanisme OAuth du standard :
auth_oauth_filter_by_domainrestreint les fournisseurs affichés sur la page de connexion selon le domaine utilisé pour accéder à l'instance. Un même Odoo servi sur deux domaines propose deux boutons de connexion différents.auth_oauth_login_fieldpermet, à la création automatique d'un compte après connexion, d'utiliser un login distinct de l'adresse transmise par le fournisseur d'identité.auth_oauth_multi_token(version 18.0.2.0.0) permet à un même utilisateur de rester connecté simultanément sur plusieurs appareils — ordinateur, mobile, plusieurs navigateurs —, ce que le module standard ne permet pas.auth_oidc_environmentplace les identifiants des fournisseurs OIDC — identifiant et secret client — dans un fichier de configuration serveur au lieu de la base.
Le module de sessions simultanées répond à une gêne quotidienne : un utilisateur connecté en authentification unique sur son ordinateur est déconnecté dès qu'il ouvre Odoo sur son téléphone. Le comportement est si contre-intuitif qu'il est pris pour une panne.
users_ldap_mail étend l'annuaire LDAP : il permet de mapper explicitement l'attribut utilisé pour le nom et l'adresse à la création automatique d'un utilisateur. Sans lui, le mapping est implicite et varie selon l'annuaire.
L'accès programmatique
Deux mécanismes coexistent pour qu'une application tierce accède à Odoo : les clés d'API et les jetons JWT.
auth_api_key_group(LGPL-3) permet de regrouper les clés d'API sous des groupes nommés. Le regroupement n'a aucun effet direct : il sert à d'autres modules pour restreindre un accès à un groupe de clés.auth_api_key_server_env(LGPL-3) place la valeur réelle des clés dans le fichier de configuration serveur plutôt que dans la base.auth_jwt(LGPL-3) authentifie des requêtes HTTP par jeton JWT transmis dans l'en-tête, plutôt que par identifiants ou par clé. Les validateurs se configurent sous Paramètres ▸ Utilisateurs & Sociétés ▸ JWT Validators. Ce module n'a aucune dépendance.auth_jwt_demoest un module de démonstration et de test : il ne s'installe pas en production.
Le placement des clés d'API dans un fichier serveur n'est pas une préférence : une clé en base voyage avec chaque copie de production. Une base de recette détient alors des clés valides sur les systèmes réels — et un script de test peut y écrire.
Le choix entre clé d'API et jeton JWT dépend de l'appelant : une clé convient à un système interne de confiance, un jeton à une application mobile ou à un service dont l'accès doit expirer.
Les interfaces de programmation et leurs cadres sont traités dans exploiter une instance Odoo pour le volet exploitation.
Les accès particuliers
cross_connect_client permet aux utilisateurs d'une instance de se connecter en un clic à une autre instance Odoo distante sur laquelle le module serveur correspondant est installé. Menus sous Paramètres ▸ Technique ▸ Cross Connect.
cross_connect_server est le pendant : il autorise d'autres instances configurées comme clientes à se connecter sur celle-ci. Il dépend d'un cadre de services web.
La connexion croisée répond à un besoin de prestataire ou de groupe : un administrateur gère dix instances et ne veut pas dix jeux d'identifiants. Elle crée aussi un chemin d'accès entre instances — qui doit être tracé et restreint au même titre qu'un accès administrateur.
base_group_subcontractor ajoute un groupe de sécurité isolé, nommé sous-traitant, dans la catégorie des types d'utilisateur. Il simule un utilisateur interne : accès au back-office, mais avec le minimum de permissions.
C'est la réponse au cas fréquent du prestataire externe : un portail ne suffit pas — il a besoin d'écrans de back-office —, et un utilisateur interne ordinaire en voit trop.
Limites connues
- Déporter l'identité vers un fournisseur externe crée une dépendance : son indisponibilité empêche toute connexion. Conserver un compte administrateur local.
auth_samlet les modules OAuth couvrent l'authentification, pas l'autorisation : les groupes Odoo restent à attribuer, manuellement ou par règle.auth_oauth_multi_tokenautorise des sessions simultanées : c'est voulu, mais cela multiplie les sessions à invalider en cas de compromission.auth_jwtn'a aucune dépendance et n'impose aucune politique : la validité, la portée et l'émetteur des jetons sont à définir dans les validateurs.auth_jwt_demone doit pas être installé en production : son README le dit explicitement.- La connexion croisée ouvre un chemin entre instances : à restreindre par les droits et à inscrire dans la cartographie des accès.
- Le groupe sous-traitant est un point de départ : les permissions réellement nécessaires restent à ajouter, et chaque ajout élargit l'accès.
cross_connect_serverdépend d'un cadre de services web (extendable_fastapi) : une brique supplémentaire à exploiter.
Identité technique
Les treize modules viennent du dépôt OCA server-auth, branche 18.0 — dont les 27 modules sont désormais tous documentés ici. Huit sont en AGPL-3, cinq en LGPL-3. Les dépendances : auth_oauth pour les quatre extensions OAuth, auth_oidc et auth_ldap pour les annuaires, auth_api_key pour les clés, server_environment pour les identifiants hors base, extendable_fastapi pour la connexion croisée côté serveur, base_setup et web pour SAML.
L'autre fiche du dépôt : mots de passe, double facteur et usurpation de compte.
Questions fréquentes
Peut-on brancher Odoo sur un annuaire d'entreprise ?
Oui, par trois chemins : SAML2 avec auth_saml, OIDC avec le module standard et auth_oidc_environment pour sortir ses identifiants de la base, et LDAP avec users_ldap_mail pour mapper explicitement nom et adresse. Conservez un compte administrateur local : l'indisponibilité du fournisseur empêche sinon toute connexion.
Pourquoi suis-je déconnecté d'Odoo sur mon ordinateur quand je l'ouvre sur mon téléphone ?
Parce que le module OAuth standard n'autorise qu'une session. auth_oauth_multi_token permet des sessions simultanées sur plusieurs appareils. Le comportement par défaut est si contre-intuitif qu'il est pris pour une panne. Contrepartie : plus de sessions à invalider en cas de compromission.
Clé d'API ou jeton JWT pour une application tierce ?
Une clé d'API convient à un système interne de confiance : elle ne change pas. Un jeton JWT (auth_jwt) convient à une application mobile ou à un service dont l'accès doit expirer — la validité, la portée et l'émetteur se définissent dans les validateurs. Dans les deux cas, sortez les secrets de la base.
Pourquoi sortir les clés d'API de la base de données ?
Parce qu'une clé en base voyage avec chaque copie de production. Une base de recette détient alors des clés valides sur les systèmes réels, et un script de test peut y écrire. auth_api_key_server_env place leur valeur dans le fichier de configuration serveur.
Comment donner accès au back-office à un prestataire externe ?
base_group_subcontractor ajoute un groupe isolé simulant un utilisateur interne, avec le minimum de permissions. C'est la réponse au cas fréquent : un portail ne suffit pas — le prestataire a besoin d'écrans de back-office — et un utilisateur interne ordinaire en voit trop. C'est un point de départ : chaque permission ajoutée élargit l'accès.
Se faire accompagner
La question de l'identité se tranche au moment où une instance dépasse une dizaine d'utilisateurs, et pas après : brancher un annuaire sur une base où les comptes ont été créés à la main suppose de rapprocher deux référentiels d'utilisateurs.
Nous instruisons donc ce choix tôt, nous conservons toujours un compte administrateur local, et nous sortons de la base tous les secrets d'accès — clés d'API comme identifiants de fournisseur d'identité. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
En résumé
Dès qu'une PME dépasse une dizaine d'utilisateurs, la question n'est plus « quel mot de passe » mais « où vit l'identité ». Treize modules branchent Odoo sur un annuaire — SAML, OIDC, LDAP — et donnent aux applications tierces des clés ou des jetons. Parlons de vos accès.
