Oauth2 est la norme

Oauth2 fait partie des standards industriels qui simplifient grandement l'utilisation du web.

OAuth2 permet de gérer les autorisations pour un grand nombre d'appareils connectés à Internet, à partir d'une identification unique sur un site de confiance. Partager et divulguer un mot de passe au sein d'une équipe qui bouge n'est pas une bonne pratique, de la même manière que centraliser l'authentification sur un LDAP (so 90's) ce n’est pas efficient avec les trousseaux des navigateurs webs.

Oauth2 comme tout bon acronyme amène avec lui d'autres chouettes acronymes, comme OpenID et JWT.

Oauth2 permet d'utiliser divers services et sites web en se loguant une seul fois, sans avoir à créer des comptes un peu partout et de maintenir à jour les informations personnelles.

OAuth2 spécifie bien le dialogue entre le fournisseur et le client, le jeton généré par le fournisseur pour le client est spécifié par JWT (Json Web Token), par contre, les données métiers contenues dans ce jeton sont plus libres. OIDC (OpenID) normalise une partie de ces informations, mais les groupes OIDC sont très vagues, et les fournisseurs OAuth2 vont donc fournir des informations spécifiques, qui nécessiteront une adaptation coté client.

Fournisseurs

Il existe une multitude de fournisseurs OAuth2, comme Google, Facebook et autres mammouths de l'Internet, mais dans notre cas, chez Bearstech, notre fournisseurs OAuth2 favori est l'inégalable Gitlab.

Clients

Oauth2 est un standard très utilisé. Il est intégré à différents services comme Sentry ou Grafana. La majorité des langages dispose de la bibliothèque qui va bien, voir même des intégrations spécifiques à différents frameworks.

On l'a testé IRL avec du Golang et du Python, avec des bibliothèques matures, agréables à utiliser. Ce qui est moins agréable, c'est que le fournisseur doit pouvoir causer avec le site client, ce qui complique le travail en local. Cela reste possible avec des fournisseurs simples à déployer comme Keycloak.

L'autre défi avec OAuth2, c’est que ça parle de sécurité. Et quand on cause sécurité, on a tout de suite la pression de faire une vraie connerie, avec de vraies conséquences, pas juste une erreur 500 tout juste humiliante.

Il est possible d'utiliser OAuth2 sans coder, avec un produit incontournable comme OAuth2-proxy. Avec ce genre de produit, vous externalisez les contraintes de mises à jour et autres bonnes pratiques de votre application.

OAuth2-proxy

OAuth2-proxy, initié par Bitly, puis forké et maintenu par une équipe communautaire, peut se placer à coté de votre serveur web (Nginx avec auth_request, Traefik avecForwardAuth, HAproxy avec haproxy-auth-request…), votre serveur garde la main sur le flot HTTP, ou comme proxy HTTP (il sait même gérer du SSL et servir des fichiers statiques).

OAuth2-Proxy permet de définir des règles fines pour établir une autorisation, comme l'appartenance à un groupe, une liste d'emails, un domaine de mail, organisation/équipe/projet/utilisateur Github, groupe/projet Gitlab, groupe OIDC…

OAuth2-Proxy sait gérer ses sessions, ou les confier à Redis (avec même l'option Sentinel pour les clusters) pour pouvoir intervenir sur le service sans couper les sessions.

OAuth2-Proxy est cité comme référence dans pas mal de documentations, comme celle de Kubernetes.

Nos contributions

La mise en application de nos valeurs passe également par des contributions au code des applications et outils que nous utilisons au quotidien.

En voulant utiliser OAuth2-proxy, le constat a été simple : le produit sait faire plein de trucs avec Github, mais peu avec Gitlab. La notion de groupe qu'aime bien OIDC n'est pas primordiale dans Gitlab, et surtout protéger un site pour que seules les personnes participant au projet puissent y accéder tombe sous le sens.

Notre premier travail à été d'ajouter la notion de filtrage par projet Gitlab à Oauth2-proxy, pour notre service Factory.

Au-delà de la technique, les contributions à des projets open source s'inscrivent dans un échange humain avec les contributeurs et des enjeux de maintenabilité et lisibilité du code. Depuis quelques années maintenant, la suite de tests unitaires pour valider le comportement de la fonctionnalité s'ajoute à l'ensemble.

Même si les langages tendent vers une normalisation du formatage (espaces vs tabulations, retour à la ligne etc.) les choix d'organisation du code ou des frameworks de tests restent hétérogènes et l'adaptation aux règles du projet (tacites ou explicites) est à la charge du contributeur.

Sur des projets de l'envergure d'OAuth2-proxy, une fois la fonctionnalité livrée, le code sera rapidement utilisé. C'est à ce moment là que démarre la partie maintenant moyen et long terme qui comprends aussi bien du support utilisateur, de la correction de bug et de l'évolution de code 

Ces contributions sont essentielles et permettent aux logiciels libres d'avancer à grande vitesse en s'adaptant directement aux besoins des utilisateurs. Pour les développeurs, elles permettent d'appronfondir les connaissances tout en facilitant les échanges avec des pairs dans un objectif d'amélioration continue de l'humain et du logiciel. Ces contributions sont essentielles et permettent aux logiciels libres d'avancer à grande vitesse en s'adaptant directement aux besoins des utilisateurs. Pour les développeurs, elles permettent d'approfondir les connaissances tout en facilitant les échanges avec des pairs dans un objectif d'amélioration continue de l'humain et du logiciel.

Crédit photo : Wikimedia : Pont des arts avec cadenas