Sur nos projets clients, nous travaillons régu­liè­re­ment avec des tech­no­lo­gies d’au­then­ti­fi­ca­tion permet­tant de délé­guer la gestion d’iden­tité à un logi­ciel pris sur étagère dont c’est le métier (par exemple : Keycloak).

La centra­li­sa­tion de la gestion de l’au­then­ti­fi­ca­tion permet d’amé­lio­rer l’ex­pé­rience utili­sa­teur : une fois la session ouverte, celle-ci peut servir à authen­ti­fier la personne auprès de plusieurs services. On parle de Single Sign On.

Derrière ces tech­no­lo­gies permet­tant de faire du Single Sign On, on retrouve le proto­cole OpenID Connect.

À nos yeux, l’éco­sys­tème Django ne propose pas d’im­plé­men­ta­tion mature, sûre et perfor­mante de ce proto­cole. Bien qu’il existe déjà des librai­ries qui implé­mentent le support d’OIDC au sein du système d’au­then­ti­fi­ca­tion Django, nous consi­dé­rons que la plupart sont basées sur des primi­tives cryp­to­gra­phiques (les librai­ries Python implé­men­tant la véri­fi­ca­tion de signa­tures RSA par exemple) qui ne sont ni sûres ni audi­tées. Les travaux à réali­ser pour robus­ti­fier ces librai­ries seraient donc consé­quents. D’autres librai­ries ont un péri­mètre fonc­tion­nel volon­tai­re­ment limité (notam­ment mozilla-django-oidc), or nous souhai­tons suppor­ter des cas d’usage avan­cés du proto­cole (back-chan­nel logout, multi-provi­der, support du mode API, etc.).

C’est pourquoi nous avons décidé d’im­plé­men­ter notre propre librai­rie d’au­then­ti­fi­ca­tion des utili­sa­teurs avec OpenID Connect, en logi­ciel libre 🎉 : ➡️ django-pyoidc ⬅️. Cette librai­rie s’ap­puie sur pyoidc pour l’im­plé­men­ta­tion des couches basses du proto­cole. Il s’agit donc de faci­li­ter l’in­té­gra­tion de cette librai­rie dans Django (comme le fait par exemple Flask-pyoidc pour Flask).

Comme nos clients ont des besoins avan­cés, la librai­rie supporte des cas avan­cés du proto­cole OIDC : gestion de plusieurs four­nis­seurs d’iden­ti­tés, gestion du back­chan­nel logout et support du mode API (DRF).

Gestion de plusieurs four­nis­seurs d’iden­ti­tés

Vous pouvez permettre aux personnes de se connec­ter avec des comptes OIDC venant de plusieurs four­nis­seurs d’iden­tité : Google, Fran­ce­Con­nect, un Keycloak auto-hébergé, etc.

Gestion du back­chan­nel logout

Lorsqu’une personne se décon­necte du SSO, celui-ci doit tuer toutes les sessions ouvertes sur les sites appli­ca­tifs. La plupart du temps, les librai­ries et appli­ca­tifs implé­mentent correc­te­ment le logout OIDC (se décon­nec­ter loca­le­ment mais aussi penser à signa­ler au SSO qu’on se décon­necte).

Le problème qui est souvent ignoré, c’est que l’uti­li­sa­teur peut aussi se décon­nec­ter depuis une autre appli­ca­tion du SSO, et termi­ner sa session de SSO.

Le SSO doit alors signa­ler à l’en­semble des appli­ca­tions clientes (dont la nôtre) que la session est termi­née.

Pour cela, le SSO a deux moyens :

• Soit le navi­ga­teur du client visite des URLs de logout de chaque appli­ca­tion, c’est le front-chan­nel logout (souvent à travers une iframe cachée dans la page de décon­nexion du SSO).
• Soit, et en termes d’UX ** on préfère plutôt cette métho­de**, le back-chan­nel logout puisque c’est le SSO qui s’oc­cupe de noti­fier les appli­ca­tions de la ferme­ture de la session avec des requêtes POST (et donc ce n’est pas le navi­ga­teur qui se décon­necte mais bien le SSO qui émet des demandes de décon­nexion).

À notre connais­sance, ce cas d’usage n’est supporté par aucune librai­rie exis­tante. Notez que si vous ne gérez ni le front­chan­nel logout, ni le back­chan­nel logout, vous pouvez à minima implé­men­ter des véri­fi­ca­tions régu­lières pour s’as­su­rer que la session de SSO est toujours valide, pour ne pas garder une session appli­ca­tive de 8 heures alors que la session de SSO est en fait termi­née (mais là encore il n’est pas rare que cet aspect soit oublié).

Suppor­ter le back-chan­nel logout suppose que vous êtes capables de détruire des sessions de Django à partir des iden­ti­fiants OIDC de ces sessions, il faut donc avoir prévu la chose lors de la créa­tion des sessions Django (enre­gis­trer les iden­ti­fiants de session SSO pour pouvoir les retrou­ver et les détruire).

Gestion du mode API

Lorsque l’on souhaite mettre en place de l’au­then­ti­fi­ca­tion sur une API gérée par django-rest-framework, le fonc­tion­ne­ment n’a rien à voir avec l’au­then­ti­fi­ca­tion clas­sique de Django. Par exemple, on ne souhaite pas redi­ri­ger les utili­sa­teurs non connec­tés vers le login mais plutôt leur renvoyer une réponse HTTP 401.

L’ap­pli­ca­tion Django ne s’oc­cupe pas d’ou­vrir la session. C’est au client (un front JavaS­cript, du curl, etc.) d’ou­vrir la session et d’en­voyer les jetons d’ac­cès au Django. Par consé­quent, on retrouve deux clients OIDC : celui qui mani­pule les creden­tials utili­sa­teur pour ouvrir une session, et celui dans Django qui sert à véri­fier les jetons.

 En conclu­sion

Bref, quand on commence à utili­ser OIDC, on trouve très souvent des programmes 'Hello World’ qui permettent de passer les premières étapes (réus­sir à authen­ti­fier l’uti­li­sa­teur sur notre appli­ca­tion). Mais nous pensons qu’il est préfé­rable d’uti­li­ser dès le départ une librai­rie qui vous permet­tra de dépas­ser cette première étape et de gérer dans le futur tous ces aspects que vous ne décou­vri­rez que plus tard. Atten­dez-vous à ce que nous publions prochai­ne­ment plusieurs articles qui vous permet­tront de dépas­ser le Hello World et de mieux comprendre OIDC.

Nous avons mis beau­coup de soin dans cet outil, et aujour­d’hui nous sommes heureux de le parta­ger avec la commu­nauté !

Si vous trou­vez des bugs, n’hé­si­tez pas à ouvrir un ticket sur le repo GitHub.