AFUP Forum PHP 2020 Baromètre Planète PHP

La parole est aux speakers : Karim Pinchon

Jusqu’au Forum PHP 2020, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

Introduction à OpenID Connect

"T'as besoin d'une application pour authentifier tes utilisateurs ? Un serveur OAuth2 c'est ce qu'il te faut !"

C'est faux. Trop souvent le protocole OAuth2 est utilisé à tord pour authentifier des utilisateurs. Ce n'est pas fait pour ça. En revanche, un protocole relativement semblable existe dans ce but : OpenID Connect.

Je vous propose de vous expliquer comment fonctionne le protocole OpenID Connect et en quoi il est différent d'OAuth2, pour ne plus se tromper d'usage.

Katherine Johnson
22/10/2020
12:10-12:30

Tu as l’habitude de donner des cours de niveau Master. À ce niveau-là, comment prépare-t-on ses cours ? Quelles sont les différences avec la préparation d’un conférence ?

En effet, depuis quelques années je dispense un cours sur les Web Services d’une dizaine d’heures en M1. À ce niveau-là, j’essaie de proposer un cours en étant très précis sur certains concepts, mais je ne cherche pas à être exhaustif et à aborder tous les sujets. Il y a quelques années je donnais des cours en L1/L2 sur les bases du web, HTML, CSS, JS, PHP et là mon approche était différente : j’essayais d’aborder beaucoup de sujets sans forcément les « creuser » au maximum. L’idée étant qu’en L1/L2 on est sur de la découverte alors qu’en Master je considère qu’on doit commencer à avoir une certaine maîtrise des sujets. Un exemple : REST est encore en 2020 un style d’architecture très mal compris, et je pense que c’est en partie dû à des enseignements qui ne sont pas assez précis, qui ne vont pas au bout des choses.
Concernant les différences entre la préparation d’un cours et d’une conférence je dirais que ça dépend :). J’ai déjà fait des présentations assez proches d’un cours magistral lorsque je voulais faire découvrir un nouvel outil par exemple. Dans ce cas, on essaie de passer en revue les fonctionnalités de l’outil, et on a quelque chose d’assez linéaire. Pas forcément très fun mais ça peut être très bien quand même. Sur d’autres types de sujets, on sait qu’on ne pourra pas parler de tout alors on n’aborde qu’une petite partie du sujet mais en choisissant un axe particulier. Et puis, pour un talk il y a des contraintes bien différentes. L’une d’elles est que l’on a très peu de temps. Réussir à proposer quelque chose d’intéressant en 10, 20 ou 40 minutes ce n’est pas simple, lors d’un cours, on a plusieurs heures, on peut se permettre des digressions ou des anecdotes pour essayer d’accrocher les étudiants.

Les devs confondent souvent authentification et autorisation. À ton avis, à quoi cela est dû ?

Tout à fait d’accord ! Je pense qu’il y a plusieurs facteurs qui expliquent ça. Un des éléments de réponse est que la sécurité n’est pas souvent abordée dans les cursus de développeurs·euses (en tout cas pas à mon époque et pas dans les filières où je suis passé). Généralement, la « sécurité » dans un cursus de dev c’est un formulaire username/password, une session et terminé… Du coup, puisque la sécurité n’est pas un sujet à part entière, des concepts tels que l’identification, l’authentification, l’autorisation ne sont jamais réellement expliqués.
Je serais tenté de dire qu’en entreprise c’est parfois un peu la même chose :(. Ce n’est pas le cas partout bien évidemment, mais pour certaines personnes l’authentification des utilisateurs n’est pas une fonctionnalité au même titre qu’une fonctionnalité « métier ». On y accorde moins d’attention, moins de temps, etc … « C’est bon, c’est pas compliqué ! » Bien sûr que si ! Ce n’est pas simple du tout et c’est surtout un enjeu crucial. Surtout aujourd’hui où nos architectures logicielles sont tellement complexes avec des micro-services dans tous les sens, des interconnexions entre partenaires, des SPA, des apps natives, etc.
Peut-on dire que les devs qui confondent authentification et autorisation sont des amateurs ? Je n’irai pas jusque là ! 😉

Y a-t-il des différences significatives dans la façon de traiter les problématiques d’authentification en Java ? Quel que soit le langage, cela a-t-il évolué depuis 10 ans ?

Je ne crois pas qu’il y ait beaucoup de différences. Les concepts restent les mêmes. Évidemment l’outillage diffère. Je pense que les frameworks Java avaient de l’avance il y a quelques années sur la façon de gérer ça, mais avec les progrès des framework PHP, je suis moins sûr que ce soit le cas aujourd’hui (bon je n’ai plus fait de Java depuis Java 8…).
Clairement depuis 10 ans les évolutions autour de ces problématiques ont été énormes, en grande partie parce que, comme je l’ai dit plus haut, les archi ont évolué : les SPA, les apps mobiles, des design « api first » entre autres. Il y a 10 ans on avait le choix entre des solutions home made pas toujours très heureuses, et des solutions éprouvées, solides, mais hyper lourdes. Aujourd’hui on a pléthore de solutions qui permettent d’adresser tous les besoins, des serveurs SSO type Keycloak, de l’authentification « as a service » type Auth0, des standards ont émergé comme JWT et… OpenId Connect 😉

Le speaker

Karim PINCHON
Karim PINCHON
Développeur PHP (mais aussi Java), Karim est spécialisé en développement d'API. Le partage de connaissance est pour lui fondamental dans l'approche de son métier : il participe en tant que spectateur à des conférences de développeurs autant que possible, et il est speaker dans des meetings locaux. Il donne depuis quelques années des cours de Web services (SOAP et REST) à des étudiants de Master. Il a une sensibilité particulière sur les sujets de sécurité, d'authentification (OAuth2, OpenIdConnect) et de signature électronique (PKI), puisque ce sont des sujets sur lesquels il travaille depuis près de 10 ans.

Autres interviews

En poursuivant votre navigation sur ce site, vous acceptez l’utilisation des cookies pour améliorer votre navigation. plus d'infos

1. Qu’est-ce qu’un cookie?

Un Cookie est un petit fichier texte enregistré sur votre terminal (ordinateur, tablette, smartphone, etc.), à l’occasion de la consultation d’un service en ligne grâce à votre logiciel de navigation. Il permet à son émetteur d’identifier le terminal dans lequel il est enregistré, pendant la durée de validité ou d’enregistrement du Cookie. Lors de la consultation de notre site Internet, des informations relatives à la navigation de votre terminal sont susceptibles d'être enregistrées dans ces fichiers dits "Cookies". Ces derniers sont installés sur votre terminal, sous réserve des choix que vous auriez exprimés concernant les Cookies et que vous pouvez modifier à tout moment.

2. A quoi servent les cookies émis sur notre site ?

Seul l’émetteur d’un cookie est susceptible de lire ou de modifier les informations qui y sont contenues.
Les cookies utilisés sur notre site permettent :

3. Vos choix concernant les cookies

Vous disposez de différents moyens pour gérer les cookies. Tout paramétrage que vous pouvez entreprendre sera susceptible de modifier votre navigation sur notre site et sur Internet en général et vos conditions d'accès à certains services de notre site nécessitant l'utilisation de cookies. Vous pouvez à tout moment exprimer et modifier vos souhaits en matière de cookies, par les moyens décrits ci-dessous. L'accord sur les cookies L'enregistrement d'un cookie dans un terminal est essentiellement subordonné à la volonté de l'utilisateur du terminal, que celui-ci peut exprimer et modifier à tout moment et gratuitement à travers les choix qui lui sont offerts par son logiciel de navigation. Si vous avez accepté dans votre logiciel de navigation l'enregistrement de cookies dans votre terminal, les cookies intégrés dans les pages et contenus que vous avez consultés pourront être stockés temporairement dans un espace dédié de votre terminal. Ils y seront lisibles uniquement par leur émetteur.

Le refus des cookies Si vous refusez l'enregistrement de cookies dans votre terminal, ou si vous supprimez ceux qui y sont enregistrés, vous ne pourrez plus bénéficier d'un certain nombre de fonctionnalités qui sont néanmoins nécessaires pour naviguer dans certains espaces de notre site. Tel serait le cas si vous tentiez d'accéder à votre compte ou à votre abonnement qui nécessite de vous identifier. Tel serait également le cas lorsque nous, ou nos prestataires, ne pourrions pas reconnaître, à des fins de compatibilité technique, le type de navigateur utilisé par votre terminal, ses paramètres de langue et d'affichage ou le pays depuis lequel votre terminal semble connecté à Internet. Le cas échéant, nous déclinons toute responsabilité pour les conséquences liées au fonctionnement dégradé de nos services résultant de l'impossibilité pour nous d'enregistrer ou de consulter les cookies nécessaires à leur fonctionnement et que vous auriez refusés ou supprimés. Les choix offerts par votre logiciel de navigation Vous pouvez configurer votre logiciel de navigation de manière à ce que des cookies soient enregistrés dans votre terminal ou, au contraire, qu'ils soient rejetés, soit systématiquement, soit selon leur émetteur. Vous pouvez également configurer votre logiciel de navigation de manière à ce que l'acceptation ou le refus des cookies vous soient proposés ponctuellement, avant qu'un cookie soit susceptible d'être enregistré dans votre terminal. Pour la gestion des cookies et de vos choix, la configuration de chaque navigateur est différente. Elle est décrite dans le menu d'aide de votre navigateur, qui vous permettra de savoir de quelle manière modifier vos souhaits en matière de cookies. Selon votre navigateur, consultez le lien ci-dessous pour configurer votre navigateur et refuser les cookies :