Lecture 8 minutes

Fin octobre, a eu lieu l’édition 2020 du Forum PHP organisé par l’AFUP. Durant cet événement, les équipes Synolia ont assisté à de nombreuses conférences passionnantes. L’une d’entre elles a particulièrement retenu l'attention : celle de Karim Pinchon à propos du standard OpenID Connect.

Le sujet n’est pas inconnu chez Synolia. En effet, ce standard a été passé au crible l’année dernière par l’équipe technique du pôle Business Intelligence dans le cadre d'ateliers R&D autour de l’embedded analytics.

Aujourd’hui, on prend la plume (virtuelle) et on vous explique tout !

OpenID Connect, brièvement et concrètement

OpenID Connect, abrégé OIDC, est une couche standardisée qui vient enrichir le protocole 0Auth 2.0 pour permettre de faire de la délégation d’authentification. Pour comprendre la différence entre 0Auth 2.0 et OIDC, n'hésitez pas à visualiser la conférence de Karim Pinchon.

Déléguer une authentification signifie remettre la tâche d’authentifier un utilisateur à un autre service, souvent jugé plus compétent en la matière ou plus pratique pour les utilisateurs.

C’est notamment ce qu’il se passe lorsqu’un fournisseur de service (relaying party) permet de se connecter avec son compte Google. Le service délègue le processus d'authentification à un fournisseur d’identité (Identity Provider, IdP), ici Google. Ce dernier est alors chargé de valider l’utilisateur prétendu.

Anecdote : vous devez tous connaitre FranceConnect, ce service d’authentification qui vous permet de vous connecter à différents services de l’administration française ! Et bien il repose lui aussi sur Open ID Connect !

Plusieurs stratégies possibles

Le fournisseur de service peut donc tirer parti d’OpenID Connect pour mettre en place différentes stratégies d’authentification en déléguant la tâche à un ou plusieurs IdP, en complément (ou non) de sa propre capacité à authentifier ses utilisateurs. Cela ne veut pas dire que le fournisseur de service substitue sa base d’utilisateurs. Il va simplement la compléter avec quelques informations supplémentaires, relatives à l’identification de ses utilisateurs lorsqu’ils sont authentifiés par un IdP externe.

Mais pour que le fournisseur de service puisse identifier avec fiabilité les utilisateurs qui s’authentifient au sein d’un autre système, il faut que ce dernier l’informe d’une nouvelle authentification et lui retourne un identifiant unique et intègre relatif à l’utilisateur authentifié. C’est là qu’entrent en jeu les spécifications d’OpenID Connect.

Flux génériques et spécifications

Tout d’abord, sachez qu’il existe plusieurs types de flux, aussi appelé Grant Flow. Ces flux déterminent les différentes étapes à réaliser durant le processus d’authentification. Ils peuvent donc varier en fonction du contexte et du type d’application qui exploite le protocole OIDC.

Cet article se concentre sur le Basic Authentication Flow, car c’est le type d’application le plus commun développé chez Synolia. Il s'agit d'applications web modernes dont une partie s'exécute côté client dans le navigateur et l’autre côté serveur. Voici le schéma des différentes étapes d'un processus d’authentification reposant sur le modèle de Basic Authentication Flow dans le cadre du protocole Open ID Connect :

Reprenons rapidement ces différentes étapes :

• L’utilisateur se rend sur l’application cliente du fournisseur de service et souhaite se connecter.
• L’application redirige l’utilisateur vers le fournisseur d’identité (IdP) en charge de l’authentifier.
• L’utilisateur s’authentifie à l’aide de ses identifiants auprès de l’IdP.
• A la suite de quoi, le fournisseur d’identité appelle l’adresse de callback qui pointe vers le fournisseur de service tout en y ajoutant un code à usage unique.
• La partie serveur du fournisseur de service consomme ce code à usage unique afin d’obtenir un jeton d’accès. Pour cela, elle fournit aussi les certificats en sa possession qui l’autorisent à réaliser cette opération.
• Avec ce jeton d’accès, le fournisseur de service est en mesure de récupérer les informations de l’utilisateur venant d’être authentifié. Ce qui lui permet de faire le lien avec l’utilisateur qu’il a dans sa base de données. C’est également ce qui permet aux fournisseurs de service de pré-remplir certaines informations au moment d'une inscription, comme le nom, prénom et adresse email.

Ainsi, un certain nombre de prérequis sont nécessaires à la mise en œuvre de ce Grant Flow.

Tout d’abord, le fournisseur de service doit être connu du fournisseur d’identité. En tant qu’administrateur de mon-service.com, je dois enregistrer mon application auprès du fournisseur d’identité pour lui faire savoir que je vais lui envoyer des utilisateurs à authentifier, ainsi que l'adresse à laquelle je veux que ceux-ci soit redirigés une fois que c'est fait (adresse de callback). Aussi, le fournisseur d’identité doit me délivrer en amont les certificats qui autoriseront à réaliser des opérations sur son API (Token et UserInfo endpoints) à fournir au moment d’y faire appel. De mon côté je dois être capable de réagir à l’appel qui sera fait sur l’adresse de callback et de consommer le code à usage unique qui me sera envoyé.

Des éléments de la spécification doivent donc être implémentés par le fournisseur de service et d’autres par le fournisseur d’identité. C’est ce qu’on appelle communément la partie Client et la partie Serveur d’OIDC. Il est important de bien identifier quels éléments vous concernent l'un et l'autre lors de l'intégration d'un protocole Open ID Connect à des services.

• Partie Client : pour déléguer l'authentification à un tiers.
• Partie Serveur : pour se proposer comme IdP d’un autre service.

Intégrer Open ID Connect

Intégrer Open ID Connect à des services n’est pas trivial. Il existe plusieurs types de flow qui comprennent chacun un certain nombre de prérequis. Heureusement, il existe déjà un certain nombre de librairies implémentant en partie ces spécifications. On peut même retrouver une liste des librairies certifiées implémentant OIDC dans différents langages de programmation.

Attention, comme vu plus haut, il faut bien distinguer celles qui implémentent la partie Serveur de la spécification (pour les IdP) et celles qui implémentent la partie Client (pour les fournisseurs de service). Vous pouvez très bien tomber sur une librairie compatible avec votre framework favori mais qui n’implémente pas la partie des spécifications dont vous avez besoin. Et c’est là le problème, ces librairies ne sont pas toutes maintenues, complètes ou conçues de sorte à pouvoir être intégrées facilement dans des plus gros projets existants.

La tâche est si complexe que certaines entreprises se sont spécialisées dans ce domaine en offrant des services dans le Cloud qui agrègent les IdP en implémentant les spécifications nécessaires. Ils mettent alors à disposition un SDK permettant aux développeurs de proposer un SSO complet à leurs utilisateurs sans s'embarrasser de la complexité technique liée aux spécificités de chaque IdP (tous ne respectant pas forcément les spécifications OIDC, voir se basant sur un protocole maison).

Parmi les principaux acteurs du marché, on peut citer Auth0 ou encore Okta. Deux services que l’on retrouve d’ailleurs proposés par défaut dans Qlik SaaS.

Le SSO, Saint Graal de l’expérience utilisateur

Autrefois réservé à quelques spécialistes, le SSO, autrement dit la capacité à s'authentifier une seule fois pour plusieurs services distincts, est aujourd’hui rendu possible à grande échelle par des initiatives comme OpenID Connect. Ce dernier rend interopérable et interchangeable les systèmes d’authentification qui respectent ses spécifications. En configurant le même fournisseur d’identité pour tous ses services, alors une entreprise fait bénéficier à ses utilisateurs de l'authentification unique.

De plus en plus de services, comme Qlik SaaS, permettent de configurer le fournisseur d’identité désiré en tirant parti d’OIDC. Synolia explore donc la possibilité de s’appuyer dessus pour proposer la meilleure expérience possible dans ses intégrations. Aujourd’hui, c’est à l’aide d’une implémentation maison que l'agence est en mesure de proposer du SSO sur toutes ses intégrations Qlik, que ce soit au travers du Portail Analytique, du module Dataviz for Sugar ou du connecteur Oro Embedded Analytics. L’idée est simple, l'utilisateur se connecte à sa solution habituelle (Portail, SugarCRM, OroCommerce…) et est automatiquement connecté à la solution de BI Qlik. C’est invisible pour lui et cette absence de friction est ce qui lui offre la meilleure expérience d’intégration possible.

Dans le cadre du Portail Analytique, Synolia souhaite aller plus loin. C'est pourquoi l'agence explore aujourd’hui la possibilité pour ses clients de choisir le fournisseur d’identité chargé d’authentifier les utilisateurs du portail. Ce qui permettrait à ce dernier d'être inséré dans n’importe quelle chaîne d’intégration SSO. Open ID Connect semble tout indiqué pour répondre à ce type de besoin.