On voit souvent en OpenID Connect un simple système de connexion unique (Single Sign On, SSO), mais c’est passer à côté de toute la puissance du procédé : le jeton d’identité JWT regroupe, de façon indissociable et infalsifiable, l’identité de l’utilisateur final, celle de l’application cliente et les portées d’autorisation ; voyez : Définition des scopes OIDC et généralités sur leur utilisation par les applications.
Dès l’origine, OAuth et OpenID Connect ont été pensés pour protéger les données sensibles appartenant à l’utilisateur final, à qui on demande l’autorisation d’y accéder. Le vocabulaire utilisé et les exemples donnés dans les spécifications sont fortement orientés par cette vision.
Cependant, avec un peu de recul, on voit que l’on est en présence d’un ensemble de techniques qui permettent de faire aussi l’inverse : s’assurer que l’utilisateur final est bien celui qu’il prétend être et autoriser son accès à des ressources protégées ou des applications qui contiennent des données sensibles, lui appartenant ou non. Et aussi : transmettre des paramètres, tels que des portées d’autorisation.
L’authentification, lie en un objet infalsifiable et transmissible appelé Jeton d’Identité ( ID Token ) : l’utilisateur et ses données personnelles, l’application et les droits de l’utilisateur sur l’application ( ou vice-et-versa ).
Vous voulez entrer rapidement dans le vif du sujet ? Lisez ces articles : OpenID Connect : Lier une application cliente au serveur OAuthSD et Exemples complets du flux d’Autorisation.
Pour revenir à SSO (Single Sign ON), OAuthSD vous offre le meilleur : pour assurer non seulement l’inscription unique, mais encore la connexion unique (Single Login Identification, SLI) sur de multiples applications, la ré-authentification silencieuse (Silent Re-Authentication, SRA) et la déconnexion unique (Single Login Out, SLO). Voyez : SLI, SSO, SLO et SRA sont dans un bateau : OAuthSD. Alors que la plupart des implémentations exigent des développements du côté des applications clientes, OAUthSD vous offre ces fonctionnalités sans aucune modification de celles-ci. Tout ceci mis bout à bout permet d’assurer la visualisation et le management de la session OpenID Connect côté client. Actuellement, nous nous attachons à renforcer la sécurité de l’identification avec la Validation en 2 étapes (Two Factor Authentication, 2FA) .
OAuthSD s’appuie sur la librairie OAuth 2.0 Server PHP développée par Brent Shaffer. Un travail notable de DnC a consisté à encapsuler les points d’entrée de cette API dans une couche de sécurité, avec des fonctionnalités supplémentaires. Le développement respecte les spécifications, voyez : OAuthSD vers la Certification OpenID ®.
Qui a besoin d’un serveur d’authentification ?
OAuth Serveur by DnC est construit sur l’architecture OAuth 2.0. Voici un exemple d’application donné page 5 de la spécification RFC 6749 :
Par exemple, une utilisatrice finale (Propriétaire de la ressource) peut accorder à un service d’impression (Client) l’accès à ses photos protégées stockées dans un service de partage de photos (serveur de ressource), sans partager son nom d’utilisateur et son mot de passe avec le service d’impression. Au lieu de cela, elle s’authentifie directement auprès d’un serveur approuvé par le service de partage de photos (Serveur d’autorisation), qui émet les accréditations (jeton d’accès) spécifiques de la délégation du service d’impression.
De quoi s’agit-il exactement ?
Voici la traduction du résumé donné en tête de la Spécification OAuth 2.0 (RFC 6749) :
L’architecture d’autorisation OAuth 2.0 permet à une application tierce d’obtenir un accès limité à un service HTTP, soit au nom d’un propriétaire de ressource en orchestrant une interaction d’approbation entre le propriétaire de la ressource et le service HTTP, soit en autorisant l’application tierce à obtenir l’accès en son propre nom.
Analysons ce texte :
"architecture" : parce-que OAuth 2.0 fournit des fonctionnalités d’un haut niveau d’abstraction, différents protocoles l’incorporeront pour répondre à un cas de figure particulier. C’est le cas de OpenID Connect, qui étend OAuth pour fournir un protocole d’authentification, permettant aux serveur de ressources d’agir selon l’identité de l’utilisateur final et celle de l’application. C’est également le cas d’ OAuth Server by DnC (OAuthSD) qui offre un protocole de vérification des jetons ainsi qu’un service de session inter-applications.
"application tierce" : cela sous-entend que OAuth définit trois composants : l’application cliente qui accède à un serveur de ressource par l’intermédiaire d’un serveur d’autorisation, ce dernier étant physiquement distinct des deux autres composants. Notons que l’on devrait parler d’"applications tierces" car OAuth est très efficace pour contrôler les accès aux données d’un client avec différents serveurs de ressources, ce qui fait qu’OAuth est un outil indispensable pour sécuriser les échanges de données d’applications réparties dans le Cloud.
"accès limité" : c’est une allusion au mécanisme des scopes permettant de préciser, en fonction des applications et de l’utilisateur, l’étendue des données accessibles et les actions autorisées sur ces données.
"un service HTTP" : Cette spécification est conçue pour être utilisée avec HTTP (RFC2616). L’utilisation d’OAuth sur tout protocole autre que HTTP est hors du sujet. Cela en fait un système particulièrement aisé à mettre en œuvre dans le cadre d’une application Web faisant appel à des ressources HTTP REST, des web-services par exemple.
"un propriétaire de ressource" : Il est facile de se représenter ce qu’est un propriétaire de ressource dans le cas le plus courant : un utilisateur se connecte à une application qui a besoin d’accéder à des données sensibles le concernant (son identité, sa position etc.).
"soit en autorisant l’application tierce à obtenir l’accès en son propre nom" : cela démontre que OAuth n’est pas limité à offrir aux utilisateurs finaux le moyen de contrôler l’accès à leur données personnelles. OAuth a de nombreuses applications pour le contrôle des échanges entre applications et serveurs de données, ce qui prend toute sa signification dans le cas d’applications et de données réparties dans le Cloud.
Cette dernière observation est capitale pour saisir toute l’étendue des applications possibles. Dès l’origine, OAuth et OpenID Connect ont été pensés pour protéger les données sensibles appartenant à l’utilisateur final, à qui on demande l’autorisation d’y accéder. Le vocabulaire utilisé et les exemples donnés dans les spécifications sont fortement orientés par cette vision.
Cependant, avec un peu de recul, on voit que l’on est en présence d’un ensemble de techniques qui permettent de faire aussi l’inverse : s’assurer, du point de vue de la ressource, que l’utilisateur final est bien celui qu’il prétend être et autoriser son accès à des ressources protégées ou des applications qui contiennent des données sensibles, lui appartenant ou non.
OAuth 2.0 est-il un système d’authentification ?
Dans un contexte de réseau, l’authentification est le fait de prouver une identité à une application ou une ressource réseau. L’authentification suppose que l’application ou la ressource protégée, qui reçoit une demande de délivrer les informations à l’application cliente (ou d’effectuer une action, un traitement...), puisse identifier l’utilisateur final ou l’objet qui bénéficie de l’autorisation. De plus, il faut que les informations d’identification transmises soient suffisamment détaillées pour permettre à l’application dévaluer l’opportunité d’autoriser l’accès (ou l’action, le traitement etc.). Le jeton d’identité fourni par OpenID Connect offre cette possibilité, le jeton d’accès fourni par OAuth 2.0 est obscur et ne le permet donc pas.
OAuth 2.0 fournit la base sur laquelle est développée l’authentification OpenID Connect [1].
OpenID Connect
OpenID Connect est une couche d’authentification construite sur OAuth 2.0. Le serveur d’autorisation/authentification (ou OP "OpenID Provider" dans ce cas) contient des informations sur une personne. OpenID Connect est utilisé pour protéger ces informations, permettant à une application tierce (client) d’y accéder au nom de la personne. Pour autoriser la diffusion d’informations, la personne est authentifiée et le Fournisseur OpenID fournit au client des détails notamment sur l’identité de la personne et le moment de l’authentification.
En quoi OpenID Connect améliore la sécurité des applications ?
OpenID Connect protège les identifiants de connexion
OpenID Connect protège efficacement les identifiants d’accès (login, mot de passe etc.). Cela constitue un énorme avantage de sécurité en assurant que ces données ne seront jamais compromises et détournées pour accéder à des données protégées.
En effet, les applications délèguent le processus au serveur d’authentification (OP). Dans cette phase, les échanges se produisent directement entre le navigateur [2] et l’OP. Il en résulte les avantages suivants :
Les informations de l’utilisateur sont sanctuarisées sur le serveur d’authentification à laquelle il se connecte, et en particulier des opérateurs de tracking ; ainsi, un malware se substituant à l’application légitime ne peut intercepter les identifiants.
La navigation dans une application fondée sur plusieurs composants répartis sur l’Internet et l’échange de données entre ces composants sont sécurisés par un processus d’autorisation unique.
OpenID Connect protège les données sensibles des utilisateurs
Au moment de la demande de connexion à une application cliente, OpenID Connect fournit à l’utilisateur des informations sur l’auteur de l’application et sur les données personnelles auxquelles l’application souhaite accéder. Ainsi, l’utilisateur accède à l’application (ou non) en pleine connaissance de cause. OpenID Connect inverse donc le paradigme de la connexion : au lieu de demander à l’internaute (l’utilisateur final) un login et un mot de passe sans aucune justification ni garantie sur les traitements qui vont suivre, OpenID Connect présente une demande d’autorisation justifiée par des informations pertinentes sur l’application et sur ce qu’il adviendra des données personnelles de l’internaute.
OpenID Connect protège les ressources de données sensibles
S’agissant de l’accès aux serveurs de ressources protégées (par exemple un web service), OpenID Connect fournit un jeton d’identité dans lequel l’identité de l’application cliente, celle de l’utilisateur et les autorisation d’accès sont liées par une signature cryptographique qui pourra être validée par le serveur de ressource destinataire.
Comme évoqué précédemment, OpenID Connect permet d’inverser le paradigme : permettre aux ressources de données sensibles de fournir (ou non) des données en fonction de l’identité de l’application et de l’utilisateur qui en font la demande.
Avertissement : Il est important de noter que OpenID Connect, comme toute autre système d’authentification, n’assure pas la sécurité des applications ou des services de données, mais leur fournit des informations plus complètes et plus fiables sur l’utilisateur final que des méthodes d’identification plus simples. D’une part la sécurité dépendra de ce que les applications et services font de ces informations, d’autre part de leur sécurité intrinsèque ainsi que de celle du réseau.
Un travail important reste à faire du côté des applications.
OAuth 2.0 ne définit pas comment un serveur de ressources protégées doit vérifier la validité du jeton d’accès ni comment interpréter l’étendue des autorisations (scopes). De plus, ni OAuth 2.0, ni OpenID Connect ne définissent comment doit être exploitée la fonction d’authentification du côté du serveur de ressources.
Pour se convaincre de la réalité du problème, écoutons Eran Hammer, un des spécialistes d’OIDC :
"Le fait que ce soit hors du champ de la spécification découle du large éventail de moyens permettant d’établir cette connexion entre les deux entités. La question principale est la complexité de votre déploiement".
Il y a là des fonctions de sécurité entièrement à la charge des serveurs de ressources protégées. Un serveur d’authentification fournit des informations pour l’authentification de l’utilisateur et de l’application, la sécurité obtenue dépendra en définitive de ce que le serveur de ressources protégées en fait, ou n’en fait pas !
C’est la raison pour laquelle OAuthSD offre un point d’entrée Introspection ainsi que les informations sur les clés publiques, deux méthodes qui permettront aux applications de vérifier les jetons qui leurs sont transmis.
OAuthSD offre également un point d’entrée Resource qui, intégré aux applications clientes, permettra d’effectuer cette vérification en quelques lignes de code. Un must pour toute API HTTP Rest !
N’accorder aucune confiance au réseau public !
Enfin, s’agissant de la sécurité des applications et/ou des données d’une entité accédées depuis l’espace public, il ne faut accorder aucune confiance au réseau : les solutions telles que le protocole Kerberos, le VPN et le proxy, qui agissent au niveau de la couche réseau, ouvrent grand les portes du réseau local. Et que dire du proxy inverse qui répète la réponse à une requête sans tenir compte de l’origine ? Ces techniques doivent être utilisées avec discernement.
OpenID Connect se situe au niveau de la couche applicative et contribue ainsi à l’approche ZTNA : il est nullement question d’autoriser l’accès au réseau, mais à une application, et encore, avec une portée d’autorisation dépendant de l’utilisateur.
Gageons qu’avec le télétravail, beaucoup d’entreprises qui auront ouvert leur réseau dans la précipitation vont connaitre de graves accidents de sécurité !
Faciliter en toute sécurité la navigation et l’échange de données au sein d’une application multiple
OAuth a de nombreuses applications, cependant les cas suivants en illustrent bien les possibilités :
Authentification unique pour un groupe d’applications
Lorsque l’application comporte différents logiciels sur différents sites, ou utilise plusieurs serveurs (c’est le cas "dans le Cloud"), ou encore si elle est fondée sur une architecture REST (sans état ni session), il n’est pas praticable de demander à un même internaute plusieurs authentifications successives. Voyez comment OAuthSD apporte la solution sans nécessiter de modification des applications : SLI, SSO, SLO et SRA sont dans un bateau : OAuthSD.
Un cas de figure très simple est celui d’un CMS ( Wordpress, SPIP ...) auquel on souhaite adjoindre une application de forum étrangère au CMS ( SPIP, PhpBB, WP ... ). Le serveur d’authentification permet de ne demander qu’une seule fois à l’internaute de s’identifier.
Cela devient très puissant dans le cas d’une application de vente couplée à un CMS et liée avec plusieurs blogs et forums : la navigation d’un utilisateur à travers le groupe d’applications ne nécessitera qu’une seule procédure d’authentification. On peut également envisager d’autoriser l’accès de cet utilisateur aux pages publiques le concernant d’un CRM (ou plus généralement d’un ERP) lié au site de vente.
Sécurité des communication entre applications
Un cas de figure classique est celui d’une application principale faisant appel à différentes ressources qui lui sont extérieures. Une fois l’internaute authentifié sur l’application principale, les serveurs de ressources doivent être certains de l’origine des requêtes qui leur sont faites.
A minima, le serveur d’authentification permet de ne pas dévoiler le login et mot de passe de l’utilisateur aux applications tierces. Mais l’avantage déterminant d’OpenID Connect est de fournir un jeton d’identité dans lequel l’identité de l’application cliente, l’identification de l’utilisateur et les autorisation d’accès sont liées par une signature cryptographique qui pourra être validée par le serveur de ressource destinataire.
Nous vous proposons un bon exemple de mise en œuvre des principes d’OIDC : l’application DnC SaaS, un système de diffusion de logiciel en tant que service (Software as Service, SaaS). Dans cette application, OAuthSD fournit l’authentification OIDC et transmet de façon sécurisée aux applications SaaS les paramètres relatifs aux abonnements des souscripteurs.
Session inter applications
En plus des services définis par les standarts OAuth et OIDC, OAuth Server by DnC offre en exclusivité le moyen d’échanger très simplement des informations de façon sécurisée entre applications web : c’est le service de CloudSession.
Prestataires Web, protégez vos intérêts et protégez vos clients
Étant propriétaire de site web ou développeur, vous pouvez résoudre la question de l’authentification unique en la délégant à G..gle, F...book etc.. Ce faisant, vous offrez à ces prestataires une magnifique occasion d’analyse comportementale de vos clients et de ciblage publicitaire. Mieux encore : vous exigez de vos clients qu’ils enregistrent sur ces services des renseignements confidentiels, dont la plupart, au delà du pseudonyme et du mot de passe, sont parfaitement inutiles dans un simple but d’authentification !
De plus, pensez-vous que cette façon de faire est compatible avec le Règlement Général de Protection des Données (RGPD) ?
Protégez vos intérêts commerciaux
Vous pouvez penser que, de toutes les façons, la plupart de vos clients ont un compte G..gle ou F...book etc.. C’est vrai, mais tout n’est pas perdu : vous pouvez au moins faire en sorte que ces prestataires publicitaires ne pistent pas la navigation de vos clients dans vos applications ( tracking ), ce qui ne manquerait pas de provoquer l’affichage de publicité de vos concurrents dans la suite de la navigation de vos clients sur le web.
Créez la confiance
En utilisant notre plateforme d’authentification, vous montrez à vos clients que vous vous attachez au respect de leur vie privée en protégeant leurs données personnelles.
RSS 2.0