Accueil > OpenID Connect OAuth Server par DnC > Pourquoi un serveur d’authentification ?

Pourquoi un serveur d’authentification ?

Les réseaux sociaux ont vulgarisé l’authentification comme moyen pour l’utilisateur d’autoriser l’accès à ses données personnelles. D’autres n’ont vu dans OAuth que l’identification unique (Single Sign-On, SSO).

Sans négliger ces objectifs, le contrôle de l’accès des utilisateurs aux applications, et des applications aux ressources protégées, constituent l’angle d’attaque de ce site.

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 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.

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, 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.

OAuth permettant de réaliser une authentification à l’extérieur des applications, il en résulte deux avantages :
- les informations de l’utilisateur restent inconnues des applications, et en particulier des opérateurs de tracking,
- la navigation dans une application composée de 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.

De plus, au moment de la demande de connexion à une application cliente, OAuth 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. OAuth 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, OAuth 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.

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 de jetons d’accès 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 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.

"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 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 ?

L’authentification suppose que l’application protégée, qui reçoit une autorisation de délivrer les informations à l’application cliente, puisse identifier l’utilisateur final qui est à l’origine de l’autorisation.
OAuth 2.0 fournit une excellente base, mais qui doit être complétée pour assurer l’authentification [1].

OpenID Connect

OpenID Connect est une couche d’authentification construite sur OAuth 2.0. Le serveur d’autorisation (ou "fournisseur OpenID" dans ce cas) contient des informations sur une personne. OAuth est utilisé pour protéger ces informations, permettant à une application tierce (client) d’y accéder au nom d’une 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 OAuth améliore la sécurité des applications ?

En soi, OAuth 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.

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 resource destinataire.

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, ni OpenID Connect, ni finalement OAuth Server by DnC 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’autorisation fournit un jeton d’accès et des informations d’authentification, 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 !

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, 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 resource destinataire.

Session inter applications

En plus des services définis par le stantard OAuth, 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.

Notes

[1Cet article est le premier de ce site. Après avoir utilisé pendant quelques temps des jetons signés pour authentifier l’accès à des web-services, j’ai découvert fin 2015 - début 2016 grâce à Eran Hammer l’inquiétante évolution d’OAuth 2.0 et, fort heureusement, la réponse d’OpenID Connect à la question de l’authentification.

Il m’est apparu que, si l’utilisateur final était alors bien identifié, la transmission du Jeton d’Identité signé à des ressources protégées posait la question de la vérification de l’application et que la question aussi bien que la réponse étaient mal mises en évidence. Le contrôle de l’accès des utilisateurs et des applications aux ressources protégées est le fil rouge de ce site.