Les incidents de sécurité d'une PME viennent rarement d'une attaque sophistiquée : ils viennent d'un compte d'ancien salarié resté actif, d'une session ouverte sur un poste d'atelier, et d'un mot de passe d'intégration qui traîne dans un fichier de configuration.
Trois modules communautaires traitent exactement ces trois cas. Aucun ne coûte de licence, et le premier — l'authentification unique — est celui qui a le meilleur rapport effort / effet de tout le socle.
Résumé
Trois modules ferment les trois portes d'une instance : l'authentification unique branchée sur votre annuaire d'entreprise, l'expiration des sessions inactives, et une clé d'API révocable par intégration.
Le premier a le meilleur rapport effort-effet de tout le socle, parce qu'il règle le risque des comptes d'anciens salariés : désactiver le compte dans l'annuaire coupe l'accès. Deux pièges — la dépendance Python python-jose, à ne pas confondre avec jose, et un délai de session par défaut de deux heures, beaucoup trop long sur un poste partagé.
L'essentiel
auth_oidc: connexion via un fournisseur OpenID Connect (Azure AD, Keycloak, tout fournisseur compatible). Un départ coupe l'accès immédiatement.- Dépendance Python
python-joseà installer sur le serveur — à ne pas confondre avec le paquet PyPIjose, qui est différent. auth_session_timeout: expiration des sessions inactives, réglée par un paramètre système, 7 200 secondes (2 h) par défaut.auth_api_key: une clé secrète par intégration, transmise dans l'en-tête HTTPAPI-KEY, gérée depuis un écran central.- Deux fournisseurs Azure AD préconfigurés — mono-tenant et multi-tenant — désactivés par défaut.
Ce que les trois modules ajoutent à l'instance
auth_oidc | auth_session_timeout | auth_api_key | |
|---|---|---|---|
| Modèles étendus | — | — | 4 |
| Champs ajoutés | 12 | 6 | 12 |
| Menus | 0 | 0 | 1 |
| Vues | 1 | 0 | 3 |
| Version | 18.0.1.1.0 | — | 18.0.1.0.2 |
| Licence | AGPL-3 | AGPL-3 | LGPL-3 |
| Dépend de | auth_oauth | — (aucune clé depends) | base_setup |
auth_session_timeout est le module le plus discret de tout le socle : aucun menu, aucune vue, aucun modèle. Il surcharge le mécanisme d'authentification HTTP d'Odoo et se règle par un seul paramètre système. C'est aussi pour cela qu'on oublie son existence — et qu'on ne pense pas à vérifier son délai.
auth_oidc : l'authentification unique, et le problème des comptes oubliés
C'est le module qui règle le risque le plus concret d'une PME : les accès d'un salarié parti il y a six mois. Avec une authentification branchée sur votre annuaire d'entreprise, désactiver le compte dans l'annuaire coupe l'accès à Odoo — il n'y a plus de geste à ne pas oublier.
Le module étend le auth_oauth standard pour gérer OpenID Connect : récupération et vérification cryptographique du jeton d'identité (clés publiques JWKS, signature RS256), et construction du lien de connexion avec les paramètres requis — nonce, response_type, PKCE.
Mise en place avec Azure AD
- Paramètres ▸ Utilisateurs et Sociétés ▸ OAuth Providers.
- Ouvrir la fiche préexistante Azure AD Single Tenant si l'accès doit être limité aux utilisateurs de votre tenant, ou Azure AD Multitenant pour ouvrir à d'autres organisations. Les deux sont créées par le module et désactivées par défaut.
- Côté Azure : créer une application web avec OpenID et le flux « code », avec l'URL de redirection
<url du serveur>/auth_oauth/signin. - Renseigner sur la fiche Odoo : Auth Flow, Client ID, client_secret, Token URL, JWKS URL, et éventuellement End Session URL pour gérer la déconnexion côté fournisseur.
- Compléter Token Map si les claims de votre fournisseur ne correspondent pas aux clés attendues par Odoo.
- Cocher Allowed (champ standard d'
auth_oauth) pour rendre le fournisseur visible sur la page de connexion.
Le piège d'installation à connaître avant de commencer : le module déclare une dépendance Python externe, python-jose, indispensable au décodage et à la vérification des jetons. Il ne faut pas la confondre avec le paquet PyPI nommé jose, qui est un autre projet. Sur un hébergement que vous ne maîtrisez pas, c'est la première chose à faire vérifier.
Le flux à choisir
Deux flux sont proposés : authorization code, recommandé, et implicit, déconseillé. Il n'y a pas d'arbitrage à faire — prenez le premier. Le second existe pour la compatibilité avec des fournisseurs anciens.
auth_session_timeout : le réglage qu'on ne trouve pas
Ce module n'a pas d'interface. Son délai se règle dans un paramètre système, ce qui en fait le réglage de sécurité le plus souvent ignoré d'une instance.
- Activer le mode développeur si nécessaire.
- Paramètres ▸ Technique ▸ Paramètres ▸ Paramètres système.
- Chercher la clé
inactive_session_time_out_delay. - Le champ Valeur contient le délai en secondes — valeur installée par défaut : 7200, soit deux heures.
- Modifier et enregistrer : le module invalide son cache à l'écriture, la nouvelle valeur s'applique aux requêtes suivantes.
À chaque requête d'un utilisateur connecté, le serveur compare la date de dernière activité de la session au délai configuré. Au-delà, la session est terminée proprement et l'utilisateur revient à l'écran de connexion. Certaines URL techniques sont exclues du contrôle, pour ne pas prolonger une session par du trafic automatique.
Quel délai choisir ? Deux heures conviennent à un poste individuel. Sur un poste partagé — atelier, magasin, caisse — c'est beaucoup trop : visez 15 à 30 minutes. C'est précisément la situation où une session oubliée donne accès aux données de l'entreprise à quiconque passe.
auth_api_key : une clé par intégration, révocable séparément
Toute intégration — un script, un système tiers, un connecteur — doit s'authentifier. Le réflexe est d'utiliser le mot de passe d'un utilisateur, souvent un compte administrateur, souvent partagé entre plusieurs intégrations.
auth_api_key remplace cela par une clé secrète transmise dans l'en-tête HTTP API-KEY, pour les routes Odoo configurées avec auth='api_key'.
| Mot de passe utilisateur | auth_api_key | |
|---|---|---|
| Révocation d'une seule intégration | Impossible sans casser les autres | Oui, clé par clé |
| Traçabilité | Toutes les intégrations sont « admin » | Chaque clé a son utilisateur |
| Utilisateur archivé | L'accès tombe | La clé peut rester active, selon paramétrage |
| Administration | Dispersée | Écran central |
La troisième ligne est la différence avec le mécanisme natif des clés API d'Odoo (res.users.apikey) : ici, la clé peut survivre à l'archivage de l'utilisateur associé, ce qui évite qu'un départ casse une intégration de production — à condition que ce soit un choix conscient.
Le module ajoute un menu : Paramètres ▸ Technique ▸ Clé API d'authentification. Une clé par intégration, nommée d'après son usage — pas « clé 1 » et « clé 2 ».
Limites connues
Deux limites répertoriées sur auth_oidc, toutes deux des manques de confort plutôt que des défauts :
- Pas de connexion directe : à l'arrivée sur l'écran de connexion, le module ne vérifie pas l'existence d'un jeton valide pour connecter l'utilisateur sans cliquer sur le lien d'authentification unique.
- Pas de déconnexion du fournisseur : une option supplémentaire pour se déconnecter aussi côté fournisseur d'identité est souhaitée mais absente. Le champ End Session URL permet d'y pourvoir partiellement.
Trois limites d'usage à connaître avant de déployer :
python-joseest une dépendance serveur, pas un module Odoo. Elle doit être présente avant l'installation.- L'expiration de session se règle hors interface, dans un paramètre système : documentez le délai retenu, sinon personne ne saura pourquoi les utilisateurs sont déconnectés.
- Une clé d'API est un secret. Elle vaut un mot de passe, et une clé lisible dans un dépôt de code vaut un mot de passe publié.
Voir les six mesures de sécurité qui comptent dans une PME et les droits utilisateurs dans Odoo.
Identité technique
| Module | Dépôt OCA | Version | Licence |
|---|---|---|---|
auth_oidc | server-auth | 18.0.1.1.0 | AGPL-3 |
auth_session_timeout | server-auth | — | AGPL-3 |
auth_api_key | server-auth | 18.0.1.0.2 | LGPL-3 |
Les trois font partie de notre socle commun. Le dépôt server-auth compte 26 modules documentés au total.
Questions fréquentes
Quel est le meilleur rapport effort / effet sur la sécurité d'Odoo ?
L'authentification unique avec auth_oidc. Elle règle le risque le plus concret d'une PME — les comptes d'anciens salariés restés actifs — parce que désactiver le compte dans l'annuaire d'entreprise coupe l'accès à Odoo. Il n'y a plus de geste à ne pas oublier.
Quelle dépendance faut-il installer pour auth_oidc ?
La bibliothèque Python python-jose, déclarée dans le manifeste du module et indispensable au décodage et à la vérification des jetons OpenID Connect. Attention à ne pas la confondre avec le paquet PyPI nommé jose, qui est un projet différent — c'est une erreur d'installation classique.
Où se règle le délai d'expiration des sessions ?
Dans un paramètre système : Paramètres ▸ Technique ▸ Paramètres ▸ Paramètres système, clé inactive_session_time_out_delay, en secondes. La valeur par défaut est 7 200, soit deux heures. Sur un poste partagé — atelier, magasin, caisse — visez plutôt 15 à 30 minutes.
Pourquoi ne pas utiliser le mot de passe d'un utilisateur pour mes intégrations ?
Parce qu'une seule intégration compromise oblige à changer le mot de passe, donc à casser toutes les autres. Avec auth_api_key, chaque intégration a sa clé, révocable séparément, et l'écran central montre qui a accès à quoi.
auth_oidc fonctionne-t-il avec autre chose qu'Azure AD ?
Oui, avec tout fournisseur compatible OpenID Connect — Keycloak par exemple. Deux fournisseurs Azure AD sont simplement préconfigurés et désactivés par défaut, pour faire gagner du temps sur le cas le plus courant. Pour un autre fournisseur, il faut renseigner les URL de jeton et de clés JWKS à la main.
Se faire accompagner
L'authentification unique est le chantier le plus rentable de cette fiche, et le seul qui demande une coordination : il touche votre annuaire d'entreprise, la configuration de l'application côté fournisseur, et une dépendance Python sur le serveur.
Nous le mettons en place de bout en bout — application côté fournisseur, dépendance serveur, mappage des claims, et le réglage du délai de session adapté à vos postes partagés. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
- auditlog : savoir qui a modifié quoi dans Odoo
- Les six mesures de sécurité qui comptent dans une PME
- Le socle commun : les 57 modules de chaque instance
En résumé
Trois portes, trois modules : l'annuaire d'entreprise pour les comptes, un délai pour les sessions oubliées, une clé par intégration. Deux pièges — la dépendance python-jose à ne pas confondre avec jose, et un délai de session par défaut de deux heures, beaucoup trop long sur un poste partagé. Parlons de vos accès.
