IREX - Sécurisation d'applications sans support OIDC natif via OAuth2-Proxy

1. Introduction

Vous utilisez peut-être Prometheus pour surveiller vos serveurs, Grafana pour visualiser vos données, ou une application métier critique développée en interne. Ces outils sont indispensables, mais ils partagent souvent un même talon d'Achille : leur système d'authentification est inexistant ou archaïque. Un simple login/mot de passe, parfois même aucun accès restreint.
Or, dans une entreprise, on souhaite une authentification centralisée, robuste, avec un annuaire unique (LDAP/Active Directory) ou un fournisseur moderne comme Keycloak. On veut que chaque utilisateur ait un seul mot de passe pour tout, avec des règles de sécurité cohérentes. Que faire quand l'application ne parle pas le langage des standards modernes comme OpenID Connect ? Il existe une solution élégante, simple et éprouvée : OAuth2-Proxy.

2. Qu'est-ce que OAuth2-Proxy ?

OAuth2-Proxy est un petit logiciel qui se place entre vos utilisateurs et votre application. Il agit comme un gardien. À chaque requête, il vérifie si l'utilisateur est déjà authentifié. Si ce n'est pas le cas, il le redirige vers un fournisseur d'identité (Keycloak, Google, Auth0, etc.), attend qu'il se connecte, puis le renvoie à l'application.
Pour l'application, rien ne change. Elle reçoit la requête comme si elle venait directement de l'utilisateur. Pour l'utilisateur, il voit une page de connexion familière (celle de Keycloak par exemple), puis accède à l'application. Pour l'administrateur, il gagne une couche de sécurité sans avoir à modifier une seule ligne de code
Le nom "OAuth2-Proxy" peut sembler technique, mais il décrit parfaitement son rôle : un proxy (un intermédiaire) qui utilise le protocole OAuth2 pour déléguer l'authentification à un tiers de confiance.

3. Pourquoi OAuth2-Proxy est-il devenu indispensable ?

De nombreuses applications modernes, notamment dans le domaine de l'observabilité (Prometheus, Grafana, Zabbix) ou de l'administration (Jenkins, SonarQube, etc.), sont livrées avec des systèmes d'authentification minimaux, voire inexistants. Pourquoi ? Parce que leurs développeurs considèrent que l'authentification est gérée par un reverse proxy ou une passerelle.
C'est exactement ce que propose OAuth2-Proxy. Il n'essaye pas de réinventer la roue. Il s'appuie sur des standards ouverts (OAuth2, OpenID Connect) pour s'interfacer avec les fournisseurs d'identité du marché.
Sans OAuth2-Proxy, vous seriez confronté à plusieurs problèmes :

• Authentification à répétition : chaque application a sa propre base d'utilisateurs, ses propres mots de passe.
• Sécurité fragile : les mots de passe sont souvent en clair, stockés dans des fichiers de configuration, sans double authentification.
• Absence de déconnexion centralisée : si un employé quitte l'entreprise, il faut supprimer ses comptes sur chaque application une par une.
• Audit impossible : on ne peut pas tracer facilement qui s'est connecté à quelle application.

Avec OAuth2-Proxy, ces problèmes disparaissent. Une seule authentification (SSO), une seule source de vérité (Keycloak ou autre), et une seule politique de sécurité.

4. Comment fonctionne OAuth2-Proxy ?

Imaginons que vous ayez une application sur https://mon-application.com, que vous vouliez protéger avec Keycloak. Vous installez OAuth2-Proxy sur la même machine (ou sur une machine proche). Vous configurez votre serveur web (Nginx) pour qu'il envoie tout le trafic à OAuth2-Proxy avant qu'il n'atteigne l'application.
Premier accès (utilisateur non connecté) :

• L'utilisateur tape https://mon-application.com.
• Nginx transmet la requête à OAuth2-Proxy.
• OAuth2-Proxy n'a pas de cookie de session, donc il génère un identifiant aléatoire et redirige l'utilisateur vers Keycloak, en lui passant une adresse de retour.
• Keycloak affiche sa page de login. L'utilisateur entre ses identifiants.
• Keycloak vérifie les identifiants, puis redirige l'utilisateur vers OAuth2-Proxy, à l'adresse https://mon-application.com/oauth2/callback, avec un code temporaire.
• OAuth2-Proxy reçoit le code, contacte Keycloak pour l'échanger contre un jeton, valide le jeton, et crée un cookie de session chiffré.
• Maintenant que l'utilisateur est authentifié, OAuth2-Proxy transmet sa requête initiale à l'application.
• L'application répond, et la réponse repasse par OAuth2-Proxy puis Nginx, avant d'arriver dans le navigateur.

Pour l'utilisateur, cette mécanique est transparente. Il n'a vu qu'une page de login Keycloak. Pour l'application, elle n'a rien vu du tout. Pour l'administrateur, tout est centralisé.
Second accès (utilisateur déjà connecté) :

• OAuth2-Proxy reconnaît le cookie de session. Il n'y a donc ni redirection vers Keycloak, ni nouvelle demande d'authentification. La requête est immédiatement transmise à l'application.

Cette approche est rapide, sécurisée, et incroyablement efficace.

5. Les cas d'usage concrets

OAuth2-Proxy est utilisé partout où l'on veut protéger une application qui n'a pas d'authentification moderne. Voici quelques exemples réels :

• Prometheus : l'interface web de Prometheus n'a aucune authentification integree. Beaucoup d'entreprises exposent Prometheus sur Internet sans aucune protection, ce qui est une faute de sécurité grave. OAuth2-Proxy règle ce problème en ajoutant une couche Keycloak ou Google.
• Grafana : certes Grafana a un système d'authentification, mais si vous voulez le centraliser avec Keycloak, OAuth2-Proxy peut servir de solution simple pour les versions anciennes ou pour des configurations particulières.
• Jenkins : le célèbre outil d'intégration continue a son propre système d'utilisateurs, mais il est souvent complexe à synchroniser avec un annuaire d'entreprise. OAuth2-Proxy permet de déléguer toute l'authentification à Keycloak en quelques minutes.
• Applications métier internes : vous avez développé en interne une application de gestion, facturation, suivi de production. Elle a probablement une authentification maison. Avec OAuth2-Proxy, vous pouvez la brancher sur l'annuaire de l'entreprise sans retoucher une seule ligne de code.
• API privées : vous avez une API qui doit être protégée mais ne supporte pas OAuth2. OAuth2-Proxy peut la préserver tout en autorisant certaines routes publiques (health, métriques, etc.).

Du moment qu'il y a une interface web ou une API à protéger, et que l'application ne parle pas nativement OIDC, OAuth2-Proxy est la réponse.

Keycloak ou autre fournisseur ?

OAuth2-Proxy n'est pas lié à Keycloak. Il supporte de très nombreux fournisseurs OIDC :

• Keycloak (open source, auto-hébergé)
• Google (si vous utilisez les comptes Google de votre entreprise)
• Auth0 (service cloud)
• Azure AD (Microsoft)
• Okta
• GitLab
• Dex

Le paramètre "provider" dans la configuration permet de choisir celui que vous voulez. La plupart des entreprises techniques choisissent Keycloak car il est open source, gratuit, riche en fonctionnalités (double authentification, fédération LDAP, etc.) et bien documenté. Mais vous pouvez très bien utiliser OAuth2-Proxy avec Google si votre équipe utilise déjà Gmail professionnel.

La simplicité de l'installation

L'un des grands atouts de OAuth2-Proxy est sa simplicité de déploiement. Une seule commande Docker suffit à le lancer. Il n'y a pas de base de données, pas d'état lourd, pas de dépendances complexes. Une fois le conteneur démarré, il ne reste qu'à modifier la configuration de Nginx pour lui envoyer le trafic. C'est l'affaire de quelques minutes. Cette légèreté en fait un outil idéal pour les environnements conteneurisés (Docker, Kubernetes), mais aussi pour les installations traditionnelles sur serveur nu.

6. Sécurité, bonnes pratiques et limites

OAuth2-Proxy doit être utilisé avec des bonnes pratiques :

• Utilisez toujours HTTPS. OAuth2-Proxy force les cookies sécurisés uniquement si vous lui dites que le site est en HTTPS.
• Générez un cookie secret fort (openssl rand -base64 32). C'est la clé qui chiffre les sessions. Gardez-la secrète.
• Ne mettez jamais le client secret de Keycloak dans un fichier versionné. Utilisez des variables d'environnement ou des secrets managers.
• En production, désactivez "ssl insecure skip verify". Ne le gardez que pour les tests.
• Limitez les domaines email autorisés si vous voulez restreindre l'accès à certains utilisateurs.
• Mettez à jour régulièrement l'image Docker de OAuth2-Proxy pour bénéficier des correctifs de sécurité.
• Avec ces précautions, OAuth2-Proxy apporte un niveau de sécurité très élevé à vos applications.

Cependant, il a quelques limites à connaître :

• OAuth2-Proxy n'est pas conçu pour faire du "logout" global (c'est le fournisseur OIDC qui le fait). Si vous voulez déconnecter l'utilisateur de toutes les applications, vous devez le faire côté Keycloak.
• Il ne gère pas l'autorisation fine (qui peut accéder à quelle page). Une fois authentifié, l'utilisateur a accès à toute l'application. Si vous avez besoin de contrôles d'accès plus granulaires, il vous faudra un composant supplémentaire.
• Il ajoute une couche supplémentaire dans la chaîne, donc un léger surcoût en latence, mais il est largement négligeable (quelques millisecondes).

Malgré ces limites, pour l'immense majorité des cas, OAuth2-Proxy fait parfaitement le travail.

7. Conclusion : Pourquoi adopter OAuth2-Proxy ?

OAuth2-Proxy est un outil mature, utilisé par des milliers d'entreprises (GitHub, Red Hat, etc.) pour sécuriser leurs applications internes. Il transforme une application aveugle aux standards modernes en une application résolument moderne, compatible SSO, sans aucune modification de son code.
Si vous utilisez Prometheus, Zabbix, Jenkins, Grafana, ou n'importe quelle application web sans authentification OIDC, l'installation de OAuth2-Proxy est probablement l'une des mesures de sécurité les plus rapides et les plus efficaces que vous puissiez prendre.
En quelques minutes, vous obtenez :
Une authentification centralisée, Un support de Keycloak (ou Google, Azure, Auth0), Une session sécurisée par cookie chiffré, Une intégration transparente pour les utilisateurs.