Accueil > OpenID Connect OAuth Serveur dédié > Découvrir

OpenID Connect permet aux applications de vérifier l’identité de l’utilisateur final sur la base de l’authentification effectuée par un serveur d’autorisation, ainsi que d’obtenir des informations sur l’utilisateur final. Par nature, le protocole assure la connexion unique de l’utilisateur à différentes applications (SSO).

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.

En quelques mots pour les utilisateurs : Après une unique procédure d’authentification, vous serez automatiquement connecté aux applications sans qu’elles puissent accéder à vos identifiants personnels (login et mot de passe). Votre mot de passe ne peut être intercepté au moment de sa saisie, ne circule pas sur Internet, n’est enregistré nulle part !

En quelques mots pour les développeurs : un serveur OAuth 2.0 + OpenID Connect permet de déléguer à un système indépendant l’authentification des utilisateurs finaux pour les laisser naviguer en toute sécurité dans vos applications ; vous accorderez une grande confiance dans l’identité réelle des utilisateurs ; vous pourrez également authentifier l’accès à des ressources réparties (par exemple dans le Cloud) et leur transmettre des informations authentifiées par le jeton d’identité (ID Token).

Pourquoi un serveur d’authentification ?

  publié le par DnC

Les réseaux sociaux ont vulgarisé l’authentification comme moyen pour l’utilisateur d’autoriser l’accès à ses données personnelles. Certains ne voient 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 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.

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

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

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.

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.

 
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.

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 et l’idée maîtresse du développement d’OAuthSD.

OAuth 2.0 et OpenID Connect : comment cela fonctionne ?

  publié le par DnC

Ce résumé permet d’acquérir une idée générale. Les développeurs se rapporteront à la rubrique Développer.

Principe

La caractéristique principale d’OAuth 2.0 comme d’OpenID Connect tient au faut fait que l’utilisateur n’a plus besoin de s’inscrire sur chaque application à laquelle il veut accéder car la procédure de connexion (la fourniture du login et du mot de passe) se passe sur le serveur d’authentification. Il est donc nécessaire de ne s’inscire qu’une seule fois. On parle d’inscription unique (Single Sign On, SSO).

Le schéma de processus ci-dessous explicite le concept :

fig 1 : L’application ne voit que des jetons, pas les identifiants personnels.

 

L’application ne voit jamais les identifiants de connexion (login et mot de passe), ni d’autres informations personnelles qui pourraient être demandées pendant la procédure d’autorisation, celles ci-circulant exclusivement, et de façon cryptée, entre le navigateur de l’utilisateur et le serveur OAuth.

Ensuite, la communication entre le serveur d’authentification et les serveurs d’applications tierces transporte des jetons (Token), et non les identifiants de connexion [1].

Sans entrer dans les détails, notons la magie qui se cache derrière "Call application with access token".
Comment le jeton est-il validé ? Il y a là un sujet généralement laissé dans l’ombre et que nous allons amplement développer, jusqu’à préconiser l’emploi exclusif d’OpenID Connect.

Avantages

La délégation d’authentification (d’une application à un serveur) présente de nombreux avantages :
- protection des identifiants de connexion (comme illustré ci-dessus),
- enregistrement unique : un seul enregistrement des login et mot de passe sur le serveur d’authentification pour se connecter à toutes les applications compatibles,
- connexion unique : une seule fourniture de login et de mot de passe pour une navigation entre plusieurs applications compatibles,
- protection de l’accès aux ressources externes tels que les web-services.

Ce dernier point mérite un développement. Alors que le point de vue sur OAuth 2.0 et OpenID Connect est le plus souvent réduit à un moyen de connexion unique (Single Sign On ou SSO), la transmission de jetons aux ressources protégées offre à celles-ci le moyen de vérifier l’authenticité de la requête qui leur est faite, en identifiant l’application qui est à l’origine de la demande [2] ainsi que l’utilisateur final. OAuthSD et OpenID Connect apparaissent alors comme un système de sécurisation global des accès à un ensemble de ressources de type web (API et web service répondant au protocole HTTP) réparties sur les réseaux.

Notes

[1Soulignons cette communication de serveur à serveur, ou "background communication" : dans le cas d’OpenID Connect, seul le flux "Authorization code" ne passe jamais les jetons par le navigateur du client final, raison pour laquelle nous mettrons au deuxième plan les autres flux dans le cadre d’OAuthSD (bien que ces flux soient implémentés par OAuthSD).

[2Cela n’est sécurisé que dans le cas des applications de type web. Voir : Authentifier l’application.

OpenID Connect et OAuth 2.0 : Synthèse des flux d’autorisation (Grant Type) Une approche Systémique d’OAuthSD

  (publié initialement le mardi 8 janvier 2019) par DnC

Les tableaux de cet article synthétisent les flux offerts par OpenID Connect et la couche sous-jacente OAuth 2.0. Il permet de naviguer vers les têtes de chapitres correspondantes de la documentation.

Pour une approche des fonctionnalités d’OAuthSD par les points d’entrée (Endpoints), voyez OpenID Connect et OAuth 2.0 : Les points d’entrée d’OAuthSD .

OAuthSD intègre la plupart des fonctionnalités d’OAuth 2.0. Les fonctionnalités d’OAuth 2.0 et de OpenID Connect peuvent être atteintes par les Points d’extrémité d’OpenID Connect.

Type de flux selon les paramètres de l’appel

1. Requêtes adressées au point d’extrémité authorize. Les différentes valeurs du paramètre response_type (obligatoire) et du scope openid (facultatif) déterminent les flux d’autorisation (Grant Type) suivants :

Grant Type response_type openid Rem.
OAuth 2.0 Authorization Code code Non RFC 6749
OIDC Authorization Code code Oui
OAuth 2.0 Implicit token X [1] RFC 6749
OIDC Implicit id_token, id_token token Oui [2] OpenID Connect Implicit Client. ’nonce’ est requis.
OIDC Hybrid code id_token Oui ’c_hash’ est requis
Hybrid code token X Invalid [3]
Hybrid code id_token token Oui Invalid [4]

Références :
- The OAuth 2.0 Authorization Framework.
- OpenID Connect Core 1.0 incorporating errata set 1 : Authentication using the Hybrid Flow.


Notes :
- A propos des response type "id_token" et "id_token token" :
ces types de réponse correspondent à des flux implicites retournant directement les jetons. Le paramètre "nonce" doit être présent dans la requête.

- A propos des response type "code token" et "code token-id token" :
ces types de réponse correspondent à des flux hybrides retournant directement le ou les jetons en même temps que le code d’autorisation. OAuthSD est fondé sur la librairie OAuth 2.0 Server PHP développée par Brent Shaffer. Dans le cadre d’OpenID Connect, celle-ci n’accepte que la demande de flux hybride "code id_token".


2. Requêtes adressées directement au point d’extrémité token. Ces flux ne sont définis que par OAuth 2.0 et ne retournent pas de jeton d’identité, que le scope openid soit indiqué ou non.

Grant Type grant_type Access Token Refresh Token Rem.
Client Credentials client_credentials Oui Oui  [4]
User Credentials [5] password Oui Non
JWT Bearer - Oui Non  [6]

References :
- RFC 6749 Client Credentials Grant,
- Spécification draft-ietf-oauth-jwt-bearer-07 section 1

Synthèse des fonctionnalités offertes par les différents flux OpenID Connect

Voir : https://openid.net/specs/openid-connect-core-1_0.html#Authentication

Propriété Flux de codes d’autorisation Flux implicite Flux hybride
Tous les jetons renvoyés depuis le contrôleur Authorization non oui non
Tous les jetons renvoyés par le contrôleur Token oui non non
Jetons non révélés à l’agent utilisateur oui non non
Le client peut être authentifié [7] oui non oui
Actualisation du jeton d’accès possible oui non oui
Communication en un aller-retour non oui non
La plupart des communications serveur à serveur oui non varie

Choix du flux en fonction de la configuration

Tous les flux n’ont pas la même valeur pour la protection des données confidentielles.
Avant de choisir un flux OpenID Connect, il est important d’identifier la configuration des parties prenantes (applications, serveur OIDC, serveurs de ressource etc.).

Cette problématique est exposée ici : Typologie des applications au regard de la sécurité des données.

Pour tester le serveur OAuthSD avec vos applications :
- Inscrivez-vous comme auteur d’applications
- Lier une application cliente au serveur OAuthSD

Notes

[1Que le scope openid soit fourni ou non, ce flux Implicite ne retourne pas de jeton d’Identité.

[2Que le scope openid soit fourni ou non, ce flux retourne toujours le jeton d’Identité.

[3Non encore implémenté dans l’état actuel du développement de la librairie OAuth 2.0 Server PHP.

[4Ce flux ne fournit pas le jeton d’actualisation. Voir : http://tools.ietf.org/html/rfc6749#section-4.4.3

[5Ou "Resource Owner Password Credentials Grant Type". Nous citons ce flux, et OAuthSD le met en oeuvre, uniquement par souci de complétude. Ce flux ne doit pas être considéré comme une authentification ; au contraire, l’utilisation de ce flux conduit à une impersonnisation (sur ce sujet, voir : https://www.scottbrady91.com/OAuth/..., nous recommendons donc de ne pas l’utiliser.

[6Cela ressemble beaucoup à l’échange de jeton décrit ici : Un jeton d’identité peut être utilisé pour ... et par cette proposition de standard : Draft IETF : Token Exchange.

[7C’est là l’essence même d’OpenID Connect. Le flux Authorization Code fournit un jeton JWT qui, par sa signature, lie le client, l’utilisateur final et la portée de l’autorisation.

OpenID Connect et OAuth 2.0 : Les points d’entrée d’OAuthSD Une approche fonctionnelle d’OAuthSD

  publié le par DnC

Cet article offre une approche des fonctionnalités d’OAuthSD par les points d’entrée [1] (Endpoints). Elle complète l’approche par les flux d’autorisation (Grant Type).

Un unique jeu de points d’entrée permet de traiter les standard OAuth 2.0 et OpenID Connect.

authorize - Point d’extrémité d’autorisation (Authorization Endpoint)

https://oa.dnc.global/authorize

Le point d’entrée Authorize est le point de départ pour les flux basés sur un navigateur, tels que le flux d’autorisation ou le flux implicite.

Le serveur assure l’identification de l’utilisateur final en lui soumettant une ou plusieurs méthodes d’authentification ainsi qu’une demande d’approbation relative à l’utilisation de ses données.

Il faut distinguer (voir OpenID Connect et OAuth 2.0 : Synthèse des flux d’autorisation (Grant Type)) :

- Les flux d’Autorisation via un code (Authorization Code Grant) qui retournent sur l’URI de retour à l’application cliente (Redirection Endpoint) un code qui permettra à cette application d’obtenir les jetons auprès du contrôleur Token. Ce type de flux permet d’authentifier l’application cliente s’il s’agit d’une application Web.
- Les flux de type Implicit ou Hybrid qui permettent d’obtenir directement les jetons. Ils ne permettent pas d’authentifier l’application cliente.

On distinguera également les flux répondant au standard OAuth 2.0 des flux OpenID Connect. Seuls les flux OpenID Connect réaliseront une authentification véritable car ils permettent d’obtenir un jeton d’identité au format JWT qui, étant signé, lie de façon sécurisée l’identité de l’utilisateur finale, celle de l’application cliente ainsi que la portée de l’autorisation.
De plus, le jeton d’identité peut être validé localement par l’application sans nécessiter de retour vers le serveur. Mais on ne peut mentionner cet avantage sans souligner que seule l’introspection permet de savoir si le jeton d’accès correspondant a été révoqué ou non.

S’agissant du jeton d’identité, OAuthSD permet d’intégrer des déclarations supplémentaires dans la charge utile du jeton JWT. Les développeurs pourront ainsi moduler les droits et privilèges de l’utilisateur final en fonction de son identité, de son appartenance ou de son profil. Un exemple particulièrement intéressant est donné par la transmission aux applications Software as Service (SaaS) des paramètres relatifs aux abonnements des souscripteurs. Une application en est donnée par le système DnC SaaS.

Dans le cadre des flux OpenID Connect, outre la fonction d’inscription unique (Single Sign On, SSO) le serveur OAuthSD implémente toutes les fonctions attendues pour le management de session : la fonction d’identification unique (Single Login Identification, SLI), la déconnexion unique (Single Login Out, SLO) ainsi que la ré-authentification silencieuse (Silent Re-Authentication, SRA), y compris avec le jeton d’identité (id_token_hint). Ceci sans modification du code d’interface des applications avec OIDC, tout étant pris en compte au niveau du contrôleur Authorize. Le Monitoring de l’état de l’authentification par les applications est également soutenu par Authorize.

token - Point d’extrémité de jeton (Token Endpoint)

https://oa.dnc.global/token

Le point d’entrée Token renvoie les jetons d’accès, les jetons d’identité et les jetons d’actualisation en fonction du type de flux et des paramètres de la demande.

Pour les flux Autorisation via un code, l’appel à Token est la deuxième étape.

Pour les flux Client Credentials, User Credentials et JWT Bearer, c’est la seule étape du flux. Ces flux ne sont définis que par OAuth 2.0 et ne retournent pas de jeton d’identité.

Notes :
- OAuthSD permet aux applications publiques d’obtenir les jetons sans dévoiler le secret de l’application avec le Flux de code d’autorisation + PKCE.
- Aucun flux défini par OpenID Connect ne s’adresse directement à Token.
- Les flux implicites définis par OAuth 2.0 comme par OpenID Connect permettent d’obtenir les jetons à l’appel d’Authorize.
- Certains auteurs définissent dans le cadre d’OAuth 2.0 un flux "Refresh Token Grant" s’adressant au point d’extrémité de jeton. Il ne s’agit pas à proprement parler d’un flux puisque, prolongeant un flux d’autorisation établi précédemment, il ne peut exister de façon autonome. Voir : Rafraîchir (actualiser) un jeton d’accès.

introspect - Point d’extrémité d’introspection (Introspection Endpoint)

https://oa.dnc.global/introspect

Une application ou une ressource protégée recevant un jeton doit toujours le valider avant de poursuivre son processus.

Le point d’entrée Introspection détermine l’état actif et les méta-informations d’un jeton. Le document RFC 7662 définit l’introspection pour un jeton d’accès dans le cadre d’OAuth 2.0.
OAuthSD étend l’introspection au jeton d’identité ID Token (au format Json Web Token, JWT) défini par OpenID Connect ainsi qu’aux jetons d’identité cryptés (au format Json Web Encryption JWE).

Notes :
- Un jeton d’accès ne peut être validé localement et ne peut l’être que par introspection.
- En revanche, un jeton d’identité (qui est signé cryptographiquement) peut aussi être validé localement. Cependant l’introspection permet de savoir si le jeton n’a pas été révoqué.
- L’utilisateur final désigné par la déclaration sub du JWT, ou sujet (subject), est considéré comme connecté par OAuthSD s’il existe un access_token valide (non expiré) pour ce sujet et le client au moment de l’introspection.

userinfo - Point d’extrémité d’informations sur l’utilisateur final (UserInfo)

https://oa.dnc.global/userinfo

Le point d’entrée UserInfo est une ressource protégée qui retourne des informations sur l’utilisateur final qui est le sujet de l’authentification.
Les demandes adressées au point de terminaison UserInfo doivent être authentifiées avec les informations d’identification du client (Client Credentials Grant) ou autorisées avec un jeton d’accès au porteur (Bearer Token).
En conséquence, l’application appelante (ou le serveur de ressource) doit être enregistrée comme cliente sur le serveur d’authentification.
S’agissant d’une spécification d’OpenID Connect, l’application appelante doit avoir été enregistrée avec le scope réservé ’openid’.

Une idée directrice du standard OpenID Connect est de demander à l’utilisateur final son accord (grant) pour l’utilisation de ses données personnelles. La réponse UserInfo est donc modulée par les portées d’autorisation (Scopes) demandées et accordées.

Puisque nous parlons des portées d’autorisation, il est malheureux de constater que le terme "Scope" couvre différentes réalités.

logout - Point d’extrémité de déconnexion (Logout Endpoint)

https://oa.dnc.global/logout.php

Le point d’entrée Logout permet de déconnecter un utilisateur au niveau du serveur d’authentification en effaçant tous les jetons d’accès qui lui sont associés. En une seule opération (Single Logout, SLO), l’utilisateur pourra déconnecter toutes les applications sur tous les terminaux à partir desquels il était connecté, ainsi que les applications qui auraient été connectées en son nom. Cependant, pour que cela fonctionne, il faut que les applications interrogent le serveur d’authentification, soit par introspection des jetons, soit par Monitoring.

Les demandes de déconnexion adressées au point de terminaison Logout doivent être authentifiées à l’aide du jeton d’identité obtenu au moment de l’authentification du client considéré.
S’agissant d’une extension d’OpenID Connect, l’application appelante doit avoir été enregistrée avec le scope réservé ’openid’.

Notons que le serveur OAuthSD exécute immédiatement la déconnexion si le jeton d’identité est valide. Un éventuel dialogue de confirmation devrait être géré côté client dans le cadre de la fonctionnalité "Monitoring".

revoke - Point d’extrémité de révocation (Revocation Endpoint)

https://oa.dnc.global/oauth/revoke.php

Le point d’entrée Revoke permet d’invalider un jeton d’accès ou de rafraîchissement.
Le jeton d’identité associé au jeton d’accès sera également invalidé.
Cependant, une application ne pourra le savoir que si elle valide les jetons par introspection ou par Monitoring.

Notons que la déconnexion (Logout) implique une révocation de tous les jetons de l’utilisateur final considéré.

keys - Point d’extrémité d’informations sur les clefs (Keys Endpoint)

https://oa.dnc.global/keys

Le point d’entrée Keys est une ressource protégée qui renvoie un jeu de clés Web JSON (JWKS) qui contient les clés publiques qui pourront être utilisées par un client pour vérifier la signature d’un jeton d’identité.

Les demandes adressées au point de terminaison Keys doivent être authentifiées avec les informations d’identification du client (Client Credentials Grant) ou autorisées avec un jeton d’accès au porteur (Bearer Token).

Notons qu’OAuthSD expose localement un contrôleur Updatekeys qui renouvelle automatiquement toutes les paires de clés publiques/privées. Ce contrôleur, par exemple, pourra être évoqué régulièrement par une tâche CRON.

resource - Point d’extrémité de ressource (Resource Endpoint)

https://oa.dnc.global/oauth/resource.php
Le point d’entrée Resource [2] renvoie des informations sur le jeton d’accès qui lui est adressé, dont sa validité.
Le client effectuant la demande ne nécessite pas d’authentification.

Découverte des points d’entrée

Conformément à la spécification OpenID Connect Discovery 1.0, OAuthSD expose ses métadonnées à l’URI :

https://oa.dnc.global/.well-known/openid-configuration

Ce sujet est traité plus en détail ici : API OpenID Connect : Découverte.

 

Pour tester le serveur OAuthSD avec vos applications :
- Inscrivez-vous comme auteur d’applications
- Lier une application cliente au serveur OAuthSD

 
A propos d’OAuthSD v2 :
OAuthSD offre maintenant un jeu unique de points d’entrée. OIDC étant construit sur OAuth 2.0, l’idée directrice est que l’approche "par le haut" depuis OIDC simplifie considérablement la compréhension.

Notes

[1Ou point d’extrémité ? Les deux termes sont employés indifféremment sur ce site.

[2Aussi connu sous le nom de Resource Owner Endpoint

Identification de l’utilisateur final

  (publié initialement le samedi 13 juillet 2019) par DnC

L’identification est la partie de l’authentification au cours de laquelle l’utilisateur final s’identifie ou est identifié. OAuthSD offre tout ce qu’il faut pour traiter l’identification (login/mot de passe, identification à deux facteurs) ou peut déléguer cette identification à un système pourvoyeur d’identité tiers (Identity Provider).

Systèmes d’identification intégrés à OAuthSD

OAuthSD distingue les fournisseurs d’identité primaire et, si l’identification à deux facteurs (2FA) est activée, les secondaires. Les constantes de configuration IDENTITY_PROVIDER et TFA_PROVIDER permettent de définir quel seront les systèmes utilisés.

OAuthSD offre en standard les systèmes d’identification suivants :

- Identification primaire (constante IDENTITY_PROVIDER) :

  • ’password’ : identification classique par login et mot de passe,
  • ’ghostkeys’ : identification par login et mot de passe entré dans une grille aléatoire.

- Identification secondaire (constante TFA_PROVIDER) :

  • ’checkbysms’ : la classique vérification par SMS,
  • ’gangsta’ : identification de type TOTP (Time-based One-time Password) avec Google Authenticator (DnC développe votre propre TOTP pour plus de sécurité).
    (plus à venir ...)

En savoir plus :
- Systèmes d’identification intégrés à OAuthSD,
- Validation en 2 étapes (Two Factor Authentication, 2FA) .

DnC’s IdentMaster

DnC développe DnC’s IdentMaster, une application de mobile permettant une identification très sécurisée de l’utilisateur final.
DnC’s IdentMaster fonctionne sans mot de passe et impose le login, réduisant ainsi les risques d’intrusion.
Fondé sur les meilleures pratiques cryptographiques, cette méthode est fermée à une utilisation publique et se trouve donc particulièrement adaptée à la sécurisation des accès aux données dans un domaine d’entreprise.

En savoir plus sur DnC’s IdentMaster.

Délégation de l’identification à un Identity Provider

Une facilité consiste à utiliser les services d’identité de Google, Facebook, Twitter etc. Cela procure certainement un grand confort pour l’utilisateur et illustre parfaitement le principe du SSO.
Cependant ce n’est pas le bon moyen d’assurer la confidentialité que l’on souhaite dans une organisation mettant en œuvre des informations protégées qui lui appartiennent. Permettre à un utilisateur de se connecter simultanément à un réseau social et à des applications métiers de l’organisation au moyen du même système d’identification est certainement ce que l’on peut imaginer de pire en matière de protection des données.

Utilisation de systèmes d’identification locaux

OAuthSD permet d’intégrer des systèmes d’identification du réseau local, qu’il s’agisse de standard tels que LADP et Active Directory (Kerberos) ou spécifiques à une organisation : ID card (Aramis) , identification biométrique etc.. Un tel système peut aussi bien se substituer à l’identification primaire que secondaire.

En savoir plus :
- Identification par OpenID Connect des utilisateurs identifiés avec Kerberos,
- Identification OpenID Connect avec ID Card : Aramis,
- Utiliser SPIP comme pourvoyeur d’identité d’OIDC.

OAuth 2.0 ou OpenID Connect ?

  (publié initialement le jeudi 20 septembre 2018) par DnC

Le serveur OAuthSD offre deux protocoles : OAuth 2.0 et OpenID Connect [1]. Lequel utiliser ? Le deuxième, évidemment !

OAuth 2.0 n’est pas un système d’authentification (l’identification de l’utilisateur final n’est pas transmise à l’application), mais un système d’autorisation. De plus, la sécurité d’OAuth 2.0 souffre de l’absence de signature des jetons. Construit sur OAuth 2.0, le protocole OpenID Connect a pour but d’apporter les fonctions nécessaires à l’identification de l’utilisateur final et de l’application cliente, tout en assurant la sécurité grâce à la signature du jeton.

Une tendance est donc de considérer OAuth 2.0 comme une infrastructure (en oubliant ses protocoles) et OpenID Connect comme un protocole construit sur OAuth 2.0.

Le jeton d’accès fourni par OAuth 2.0 est un simple hash de valeur aléatoire, non signé, donc obscur pour la ressource protégée qui le reçoit. La spécification d’OAuth 2.0 ne définit pas comment le jeton passé à un serveur de ressource doit être validé par celui-ci [2]. Ceci est laissé à l’initiative du développeur, avec un certain nombre de défauts :

- Puisqu’il n’y a pas de méthode standard, les implémentations d’OAuth sont nécessairement toutes propriétaires.

- 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). Le fait que la nécessité de vérifier le jeton n’est pas mentionnée dans la spécification ouvre la porte à des développements insuffisamment sécurisés.

- enfin, les flux OAuth 2.0, retournant des jetons non signés (alors que OAuth 1 assurait la signature !), ne sont sécurisés que si l’on peut "faire confiance" aux applications clientes (par exemple, l’URL de retour est "codée en dur" dans l’application). Autant dire qu’ils ne sont sécurisés que dans un espace propriétaire (corporate realm). Pour être utilisés dans un espace ouvert, il manque une signature pour authentifier, comme le démontre brillamment un des concepteurs d’OAuth 2.0, Eran Hammer : OAuth 2.0 (sans signature) est mauvais pour le Web :

"OAuth 2.0 supprime les signatures et la cryptographie en faveur des jetons portés, semblables aux cookies. En tant qu’éditeur d’OAuth 2.0, je suis associé au protocole OAuth 2.0 plus que la plupart des autres, et l’hypothèse est que je suis d’accord avec les décisions et les orientations prises par le protocole. Bien que le fait d’être éditeur donne un certain degré de contrôle temporaire sur la spécification, les décisions sont finalement prises par le groupe dans son ensemble (comme il se doit).
Et dans son ensemble, la communauté OAuth a commis une grave erreur (ndlr : en supprimant la signature des jetons) quant à l’orientation future du protocole. Une erreur qui fera d’OAuth 2.0 un agent de changement beaucoup moins important [3] sur le Web."

OAuthSD applique la proposition de standard RFC 7662 : OAuth 2.0 Token Introspection. OAuthSD expose un point d’entrée d’introspection qui permet de vérifier aussi bien les jetons d’accès d’OAuth 2.0 que les jetons d’identité d’OpenID Connect.

Il faut donc passer à OpenID Connect !

OpenID Connect [4] complète les fonctionnalités d’OAuth 2.0 pour apporter, avec le jeton JWT signé ou JWS [5], des informations sûres sur l’application cliente, la portée de l’autorisation (scope) et, le cas échéant, sur l’utilisateur connecté à l’application cliente.

Cependant, vérifier la signature du jeton ne suffit pas. Il ne faut pas écarter la possibilité d’un vol de jeton qui sera présenté par une application étrangère. OAuthSD prend en compte ce cas de figure (voir : Vérification de l’origine de la requête reçue par un serveur de ressource). Cette approche stricte de la sécurité conduit à la conclusion que seul le flux Authorization Code appliqué à des applications clientes de type web (avec back-end) peut être considéré comme sûr. Voyez : Typologie des applications au regard de la sécurité des données.

Que reste-t-il d’OAuth 2.0 ?

Dans un "espace de confiance" (dont les communications sont au minimum protégé par TLS), certains pourront considérer que l’identification de l’utilisateur final n’est pas nécessaire, ni la vérification de l’application cliente. Ceux-là utiliseront les flux d’OAuth 2 pour leur simplicité, et en particulier le flux Autorisation de Serveur à serveur (Client Credentials Grant) pour assurer l’accès des applications à une API protégée.

Quoi qu’il en soit, OAuth 2.0 reste une infrastructure sur laquelle sont construits de nouveaux protocoles comme OpenID connect. Une tendance est donc de considérer OAuth 2.0 comme une infrastructure (en oubliant ses protocoles mais sans oublier l’introspection) et OpenID Connect comme un protocole construit sur OAuth 2.0.

Notes

[1Noter que OpenID Connect est un standard distinct d’OpenID.

[2C’est même bien pire que cela : la nécessité de le vérifier n’est pas mentionnée. Il faut attendre la spécification d’OpenID Connect pour apprendre que le jeton d’identité doit être systématiquement vérifié. On peut se demander si un certain nombre de codeurs n’ont pas utilisé OAuth 2.0 en accordant une propriété magique au jeton d’accès. Peut-être pensaient-ils que le protocole s’occupait de tout ? Des témoignages d’informaticiens expérimentés, selon lesquels des codeurs utilisaient des bibliothèques sans même comprendre la logique des échanges entre un serveur et un user-agent, ou sans même savoir qu’il y avait des serveurs derrière l’application qu’ils développaient côté client, y compris pour des applications mobiles ou de desktop, donnent à penser que des applications ont pu fonctionner - et fonctionnent toujours - avec des failles de sécurité béantes.

[3Un euphémisme pour dire "un changement catastrophique pour la sécurité du Web".

[4Une petite subtilité : Google met en oeuvre OpenID Connect sous la dénomination OAuth 2.0.

[5Appelé "jeton d’identité (ID Token)".

Le serveur OAuth 2.0 que DnC met à votre disposition

  publié le par DnC

Avertissement : Le serveur OAuthSD installé à l’adresse oa.dnc.global est un démonstrateur et un outil de développement, il peut être indisponible et les données enregistrées effacées à tout moment. Les développeurs intéressés par une version de production de OAuthSD peuvent s’adresser à DnC

OAuthSD a été développé avec trois idées directrices : ce devait être un système sanctuarisé dans le domaine d’une organisation pour une meilleure protection des données, particulièrement adapté à sécuriser l’accès aux données selon l’utilisateur et l’application et permettant donc de mieux identifier les applications.

Dans le cadre des applications que DnC développe pour ses clients, nous avons pour ambition d’offrir un serveur d’authentification aux fonctionnalités étendues, et proposant un interface utilisateur pratique complété par une documentation accessible.

Tout en restant conforme au standard OpenID Connect, OAauth Server by DnC apporte de nombreuses améliorations fonctionnelles.

OAuth Server by DnC est conforme à La norme OAuth 2.0 (RFC 6749) et s’appuie sur la librairie OAuth2 Server Library for PHP développée par Brent Shaffer (voir : http://bshaffer.github.io/oauth2-se...).

Cette API n’assure pas l’identification de l’utilisateur ni la gestion du consentement et encore moins les fonctionnalités avancées décrites ci-après.

DnC a encapsulé cette bibliothèque dans une application serveur, en apportant les développements suivants :

- Le protocole OpenID est implémenté avec des extensions exclusives :

  • Le monitoring de l’état de l’authentification permet à l’utilisateur final de visualiser l’état de la session OIDC. L’utilisateur est averti de l’imminence de la fin de session et peut la prolonger.
  • Dans un domaine du réseau local contrôlé par Kerberos, OAuthSD utilise l’authentification Kerberos de sorte que l’utilisateur ayant initié une session locale (avec Active Directory s’agissant du système Windows) n’a pas à s’identifier à nouveau pour accéder aux application clientes du serveur OAuthSD.

- OAuthSD complète le noyau OAuth2 :

  • En offrant une API HTTP REST + TreeQL permettant d’intégrer OAuthSD dans un système de gestion des utilisateurs et des applications ainsi que la définition des privilèges.

- OAuthSD offre un interface d’exploitation et une documentation

  • Un interface utilisateur convivial (comme sur ce site web) permet de configurer le serveur et offre une documentation détaillée pour sa mise en œuvre ainsi que pour l’adaptation de vos applications.
  • Des dizaines d’événements différents sont suivis à la microseconde et sont présentés dans des graphes et tableaux interactifs permettant d’identifier avec précision les erreurs et les anomalies significatives d’abus ou de tentative d’intrusion.
  • L’administrateur du serveur est alerté par e-mail des tentatives d’intrusion et des utilisations abusives.
  • Un rôle d’Administrateur d’applications s’ajoute aux rôles définis par la norme : ceux-ci créent et gèrent sur ce serveur les applications clientes dont ils délèguent l’authentification, et dont ils sont donc propriétaires. Ils peuvent également documenter sur le site web du serveur les aspects particuliers du processus d’authentification de leurs applications (ils sont Auteurs au sens de SPIP).
  • Le modèle d’application est étendu avec des données qui permettront de gagner la confiance de l’utilisateur en l’informant avec précision sur l’identité de l’administrateur de l’application, le fonctionnement de l’application et l’utilisation des données personnelles.
  • Alors que le paramètre State est facultatif dans la définition du protocole OAuth, ce paramètre est obligatoire pour OAuth Server by DnC afin de renforcer la sécurité.
  • Lors de la procédure d’autorisation, le mot de passe de l’utilisateur final n’est pas entré au clavier, mais à la souris dans une grille aléatoire (GhostKeys). Ainsi, les mots de passe n’ont pas d’existence physique, sont cryptés dès la saisie, et ne peuvent donc être interceptés par un pourriciel. Mieux encore : avec DnC’s IdentMaster, il n’y a plus de mot de passe !

Avec OAuth Server by DnC, les mot de passe ne peuvent être interceptés au moment de leur saisie, ne circulent pas sur Internet, ne sont enregistrés nulle part !

L’engagement de DnC à ne pas divulguer les données est un moyen pour les entreprises de se protéger de la concurrence. C’est aussi un avantage concurrentiel que les entreprises peuvent faire valoir auprès de leur clients et utilisateurs finaux.

 

Pour entrer rapidement dans le sujet, voyez :
- SLI, SSO, SLO et SRA sont dans un bateau : OAuthSD,
- Exemples complets du flux d’Autorisation,
- OpenID Connect : Lier une application cliente au serveur OAuthSD.

Pour tester le serveur OAuthSD avec vos applications :
- Inscrivez-vous comme auteur d’applications
- Lier une application cliente au serveur OAuthSD

OAuthSD V2

  publié le par DnC

Après 5 ans d’existence, le code d’OAuthSD a démontré sa fiabilité. Cependant, il a été développé de façon progressive en suivant les évolutions d’OAuth 2.0 et d’OpenID Connect. Le code devenu abondant, dense et peu lisible nécessitait une réécriture.

Par ailleurs, les tests OIDF Conformance ont évolué, OAuthSD aussi : de nouveaux tests ont été effectués.

2021 : OAuthSD v2

A l’origine en 2016, il s’est agit de créer un serveur OIDC en encapsulant l’API oauth2-server-php dans un peu de code pour créer trois contrôleurs : Authorize, Token et Resource.

Depuis, la surcouche oauthsd-core-php a pris beaucoup d’extension visant à renforcer la sécurité de l’authentification. En même temps, beaucoup de fonctionnalités d’OAuth 2.0 et d’OpenID Connect, omises dans l’API, ont impliqué de nouveaux développements.

De plus, certaines extensions d’OIDC (par exemple l’introspection) avaient été développées dans la surcouche, l’idée initiale étant de conserver l’API oauth2-server-php inchangée. Nous comptions alors sur le fait que cette API se développerait, ce qui n’a pas été le cas.

Enfin, nous avions pris le parti de distinguer les contrôleurs OAuth 2.0 et les contrôleurs OIDC, ce qui créait confusion et doublons.

Le code de la surcouche oauthsd-core-php était devenu abondant, dense et peu lisible.

Il est donc apparu nécessaire de réécrire le code :

- L’application de la programmation orientée objets (OOP) a permis d’améliorer la lisibilité de la surcouche. On a également obtenu une meilleure vitesse de traitement, le temps de réponse étant réduit d’un facteur deux à cinq. Comme toujours s’agissant d’OOP, le gain de vitesse est obtenu au prix d’une augmentation de la mémoire utilisée. Notons que nous n’avons toujours pas utilisé de framework PHP, car l’expérience montre une dégradation inacceptable des performances et une utilisation prohibitive de la mémoire du serveur.

- La création d’un objet "Identification" facilite grandement la création de nouvelles méthodes d’identification de l’utilisateur ou l’intégration d’OAuthSD dans un système d’identité existant.

- Il est apparu que la distinction entre deux groupes de points d’entrée spécifiques pour OAuth 2.0 et OpenID Connect était inutilement complexe et redondante. Il n’y a maintenant qu’un seul jeu, composé des points d’entrée d’OIDC et de trois flux spécifiques d’OAuth 2.0. Le contrôleur Authorize fonctionne aussi bien selon OAuth2.0 et OIDC, en distinguant les appels OIDC avec la portée demandée ’openid’. Autre exemple, le contrôleur Introspect permet de valider aussi bien des jetons d’accès que des jetons d’identité.

- Un fork de l’API a été développé. Des fonctions auparavant développées dans la surcouche ont trouvé leur place naturelle dans l’API : l’introspection, les JWT cryptés (JWE), l’insertion de nouvelles déclarations dans le JWT (kid, acr), le traitement de la "Clé de vérification pour l’échange de code (PKCE)". Le contrôleur Resource a été amélioré et des petits ajustements ont été apportés sans s’imposer de restriction.

- Un soin particulier a été apporté au traitement de la "Référence de classe de contexte d’authentification (ACR)", qui avait été omis de l’API. Cette fonctionnalité est fondamentale s’agissant de mettre en œuvre des pourvoyeur d’identification de niveau de sécurité différents. Chaque application peut alors exiger un niveau de sécurité minimum et rejeter des identifications insuffisamment sécurisées.

- Le paramètre "max_age", qui avait été omis de l’API, est maintenant traité.

- OAuthSD implémente maintenant le paramètre ’request’ sous sa forme JWT non signé et passé par valeur (ainsi que le prévoit le test de certification de l’OIDF).

- Les commentaires dans le code ont été abondamment développés, avec de nombreuses références, afin d’offrir aux développeurs une bonne compréhension de mécanismes souvent très complexes. C’est écrit en anglais, nous sommes à la disposition des utilisateurs pour les aider au besoin.
La documentation sera refondue en conséquence. OIDC étant construit sur OAuth 2.0, l’idée directrice est que l’approche "par le haut" depuis OIDC simplifie considérablement la compréhension. D’autres penseront que OAuth 2.0 intègre les fonctionnalités d’OIDC, et qu’il est donc inutile d’en parler...
Commentaires détaillés et documentation abondante nous permettent de justifier pleinement la qualité de notre offre de transfert de compétence.

- Les tests OIDF Conformance ont évolué, OAuthSD aussi, de nouveaux tests ont été effectués. Voyez : https://oa.dnc.global/web/-Tests-et.... Le résultat des tests est visible en ligne.

En quoi OIDC contribue-t-il à l’approche ZTNA ? Perspectives d’évolution d’OAuthSD vers le contrôle du niveau matériel

  publié le par DnC

Zero Trust Network Access, ZTNA : Accès "zéro-confiance" au réseau. Ce concept formalisé en 2010 par le cabinet d’études Forrester vise à donner aux utilisateurs des privilèges justes nécessaires (contrairement à un accès au réseau par Virtual Private Network, VPN).
OpenID Connect apporte dans ce domaine certaines réponses, notamment pour une protection en profondeur, au-delà du contrôle de l’accès au réseau.

Dans le contexte du COVID-19, le télétravail conduit de nombreux employés à accéder au réseau de leur entreprise au moyen d’un tunnel VPN à partir de l’ordinateur personnel ou - horreur absolue - l’ordinateur familial. Il convient d’effectuer des contrôles à ce niveau.

Principes du ZTNA

Il s’agit de protéger le système d’information (SI) et les données sensibles en partant du principe que l’on ne doit faire confiance à rien ni personne. Du matériel de l’utilisateur jusqu’à l’application, trois principes généraux s’appliquent :

1. Contrôle des matériels utilisés pour accéder au SI : Le seul contrôle de l’utilisateur final n’est pas suffisant, il convient de contrôler également l’agent utilisateur au moyen duquel il accède au réseau et aux applications, ainsi que son matériel.
Chez DnC, nous notons que cette formulation suppose que l’application se trouve du côté du réseau local (application avec back-end). C’est donc une application bien identifiée, digne de confiance. Ce n’est pas le cas des applications fonctionnant sur des stations de travail ou des agents utilisateur distants. Il faudrait donc inclure l’authentification des logiciels dans ce premier principe.

2. Authentification multi-facteurs : l’authentification (à deux facteurs au moins, ou Two Factors Authentication, TFA) exige plusieurs preuves d’identité de l’utilisateur final.

3. Privilège minimum : Ne donner aux utilisateurs que l’accès aux ressources ou données dont ils ont besoin pour effectuer leurs tâches.

Comment se situe OpenID Connect ?

1. OpenID Connect intervient au niveau des applications. OIDC ne peut donc se substituer aux moyens d’identifier et de contrôler les couches matérielles. Cependant, le flux d’autorisation avec code (Authorization Code Grant), lorsqu’il est appliqué à des applications et services "avec back-end", offre un moyen d’identifier ces composants au niveau matériel. Sur ce sujet, voyez : Vérification de l’origine de la requête reçue par un serveur de ressource.

2. L’identification multi-facteurs ne fait pas partie de la norme OpenID Connect. La couche identification du contrôleur Authorize se doit d’implémenter plusieurs moyens d’identification, OAuthSD assure l’identification multi-facteurs.

3. En permettant de véhiculer par le jeton d’identité (ID Token) des informations d’identité et de privilèges et d’en garantir l’intégrité au moyen de la signature du jeton, OpenID Connect ouvre un moyen de contrôler les accès aux applications et aux données. OAuthSD permet la transmission des privilèges.
Cependant, tout dépend de ce que les applications et les ressources protégées feront de ces informations.

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.

En conclusion :

Les applications du principe ZTNA visent à compléter les protections de la couche transport (VPN, firewall, proxy) et s’intéressent donc à la qualification des applications et des personnes.

OpenID Connect étend la sécurité au niveau applicatif (dans la couche haute du modèle de l’OSI) et trouve donc sa place dans une approche ZTNA complète.

La difficulté d’OIDC réside dans la nécessité d’adapter les applications et les ressources de données protégées en leur incorporant un module OIDC. Voyez : Adaptation des applications.

Perspectives pour l’évolution d’OAuthSD

L’identification et le contrôle d’intégrité du matériel ainsi que des logiciels applicatifs et système est encore le parent pauvre des solutions de sécurité.

Notons que le serveur OAuthSD intègre déjà quelques fonctionnalités de sécurité au niveau des couches matérielles et transport, et en apportera de plus en plus au fur et à mesure de son développement.

Il existe des informations complémentaires, connectez vous pour les voir.

SaaS et OIDC : un mariage réussi grâce à OAuthSD !

  (publié initialement le jeudi 25 juin 2020) par DnC

Une des fonctionnalités que DnC a développées au plus haut niveau avec son serveur Open ID Connect (OIDC) consiste à transmettre des informations sécurisées au moyen du jeton d’identité JWT signé (JWS).

Nous décrivons dans cet article 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.

Position du problème

La plupart des système SaaS intègrent l’application et le système de vente dans un même logiciel.

Si différentes applications web doivent être diffusées en mode SaaS par une même entité, le premier problème à résoudre consiste à assurer le service de connexion unique (SSO) entre le système de vente et les différentes applications. Pas de problème, c’est le rôle d’un serveur OIDC, OAuthSD fait cela très bien.

Le deuxième problème, plus intéressant, consiste à transmettre des informations du système de vente vers les applications.
S’agissant de la validité de l’abonnement et des options (payantes), il faut sécuriser ces données, c’est à dire permettre à l’application destinataire de contrôler :
- l’intégrité (les données n’ont pas été falsifiées),
- l’authenticité de leur origine (elles ont bien été délivrées par le système SaaS),
- l’actualité (ce sont bien des données valides à l’instant considéré),
- la destination (ce sont bien des données relatives à cette application),
- et bien sûr l’identité de l’utilisateur final (ce n’est pas un intrus qui utilise l’application).

La solution : OAuthSD

OAuthSD permet d’intégrer les données SaaS sous forme de déclarations supplémentaires dans la charge utile du jeton JWT. Il suffira à l’application destinataire (cliente du serveur OIDC) de valider le jeton d’identité par introspection (et non localement afin d’assurer l’actualité) pour réaliser en une seule opération les contrôles décrits ci-dessus.

Le système DnC SaaS et l’une de ses applications NSS Lite illustrent parfaitement cette technique.

Pour réaliser cela, nous avons :
- intégré dans une même application le serveur OIDC et le système de vente,
- développé des plugin d’extension OIDC-SaaS notamment pour des applications fondées sur SPIP ou Wordpress .

Nous serions heureux de pouvoir assister les PME pour leur permettre de développer leur propre système de SaaS et d’adapter leurs applications web.
Notre positionnement de conseil et d’assistance permettrait un développement indépendant de prestataires extérieurs coûteux. Et de systèmes tiers hasardeux en termes de sécurité : pourquoi nourrir le big-data au profit de vos concurrents ?

Définitions

  publié le par DnC

Administrateur (d’applications), Auteur (propriétaire d’applications)

Un développeur ou un propriétaire de sites Web, utilisateur privilégié, notamment propriétaire d’une ou plusieurs applications clientes qu’il a inscrites sur ce serveur en vue de déléguer les authentifications.
Notes :
- cette notion est propre au serveur OAuthSD de DnC.
- il s’agit également d’un objet Auteur au sens de SPIP.

Autorisation

Requête de la part d’une application cliente vers :
- soit une personne (utilisateur final) à qui il est demandé d’autoriser ou de refuser l’accès à une ressource.
- soit une machine dans le cas de l’autorisation serveur à serveur.

Client, Application cliente

Un Client est une application inscrite sur ce serveur par un administrateur. Plutôt que de réaliser elle-même l’authentification des utilisateurs, l’application cliente délègue cette action au serveur OAuth. Cela permet également d’autoriser l’accès aux ressources protégées appelées par cette application.
Dans le contexte OpenID, un client est dénommé Relying Party (RP).

Diagramme de Flux (Flow Chart), Flux d’Autorisation (Grant Flow)

Représentation graphique de la séquence des échanges entre les Rôles. Il existe un Diagramme de Flux distinct pour chacun des 4 types d’Autorisation ou Flux.

Type d’Autorisation (Grant Type)

OAuthSD prend en charge plusieurs types d’autorisation, qui sont des méthodes permettant d’obtenir des jetons d’accès (valeurs de chaîne représentant les autorisations accordées). Différents types d’autorisation autorisent différents types d’accès et, en fonction des besoins de votre application et la nature des ressources, certains types d’autorisation sont plus appropriés que d’autres. Mais attention : tous ne sont pas parfaitement sécurisés !

Jeton (Token)

Le jeton est une chaine de caractères générée par le serveur d’autorisation. Il est émis en réponse à une demande de l’application cliente.

Dans le cadre de OAuth 2.0, on distingue 2 types de jetons :

- Le jeton d’accès (Access Token) : Permet au serveur d’une ressource protégée d’autoriser une application cliente à y accéder. Ce jeton est envoyé par l’application cliente en tant que paramètre ou en tant que header dans la requête vers le serveur de ressources. Il a une durée de vie limitée qui est définie par le serveur d’autorisation.

- Le jeton de renouvellement (Refresh Token ) : Utilisé pour demander de prolonger l’accès à une ressource ; envoyé sur demande d’une application qui détient déjà un jeton d’accès valide.

Le protocole OpenID Connect introduit :
- Le jeton d’identité (ID Token). De type JSON Web Token, ce jeton transporte des données relatives à l’authentification : application cliente, identité et profil de l’utilisateur final, étendue de l’autorisation. Étant crypté et signé, il offre un moyen sûr de transmettre aux ressources protégées des informations fiables sur l’authentification : utilisateur final, application, portée de l’autorisation.

Rôles

Les protocoles d’authentification de OAuth définissent les échanges entre 4 rôles :

- Le détenteur des données (Ressource Owner) : une ressource matérielle, ou une personne (Utilisateur Final), qui autorise l’accès à une ressource protégée.

- Le serveur de ressources (Ressource Server, RS) : serveur qui héberge les ressources protégées, et répond aux demandes d’accès aux ressources protégées selon le jeton d’accès (Access Token).
Dans le contexte OpenID, le serveur de ressource peut recevoir un jeton d’identité (ID Token) lui permettant d’authentifier l’utilisateur, l’application cliente et les autorisations exprimées par les portés d’autorisation (scopes).

- Le Client ou l’Application Cliente (Client, Client Application) : application demandant des ressources protégées au nom du propriétaire de celles-ci et avec son autorisation. Le client est inscrit sur le serveur d’autorisation par un administrateur d’application qui en configure les caractéristiques.
Dans le contexte OpenID, un client est dénommé Relying Party (RP) ou partie de confiance.

- Le Serveur d’autorisation (Authorization Server, AS) : serveur qui délivre des jetons d’accès (Access Token) au client après que le propriétaire de la ressource a été formellement authentifié et qu’il a obtenu une autorisation de sa part.

Dans le contexte OpenID, le serveur d’autorisation délivre un jeton d’identification (ID token) en réponse à une demande d’authentification, ce qui justifie la dénomination OpenID Provider (OP ou IdP).

Etendue (ou portée) de l’autorisation (Scope)

Les Scopes définissent l’étendue des droits ( les actions permises sur les données de la ressource ) attachés au token d’accès. La liste des Scopes disponibles est définie par l’Auteur pour chacune de ses applications clientes du côté du serveur d’autorisation. La signification d’un scope dépend exclusivement de ce que le serveur de ressources protégées en fait (ou n’en fait pas), le serveur d’autorisation étant transparent à cet égard.

URI de redirection (Redirect URI)

Une URI absolue de l’application cliente à laquelle le serveur redirige l’user-agent de l’utilisateur final à la suite du processus d’authentification, et à laquelle il adresse le résultat.

Utilisateur, utilisateur final (End User)

Internaute répondant aux requêtes d’authentification. Ses identifiants sont inscrits sur le serveur d’authentification (et non du côté des applications clientes).

 

Mentions légales

  publié le par DnC

Avertissement

Avertissement 1 : 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.

Avertissement 2 : Ce site un démonstrateur et un outil de développement, il peut être indisponible et les données enregistrées effacées à tout moment.

Cette application est un prototype en développement. Elle est destinée à permettre aux développeurs de tester OAuthSD dans leurs applications clientes et leurs serveurs de ressources protégées. Toute utilisation se fait aux risques et périls de l’utilisateur.

La documentation est également en devenir constant et ne saurait remplacer les documents auxquels elle fait référence.

L’utilisateur est averti des différences pouvant exister entre le serveur OAuthSD et les spécifications d’OpenID Connect : toutes les fonctionnalités ne sont pas nécessairement implémentées par OAuthSD ou ne le sont pas encore, certaines spécifications sont encore à l’état de proposition, certaines fonctionnalités sont jugées peu utiles ou peu sécurisées. De plus, OAuthSD offre quelques extensions intéressantes qui, sans aller à l’encontre du standard, n’en font pas partie. Enfin, OAuthSD est destiné à être mis en oeuvre dans le cadre fermé que constitue un ensemble d’applications d’une même entité ce qui autorise une certaine liberté par rapport aux spécifications.

DnC n’offre aucune garantie et nie toute responsabilité pour quelque dommage que ce soit résultant de l’application ou de la documentation.

Droits

L’ensemble de ce site relève de la législation française et internationale sur le droit d’auteur et la propriété intellectuelle. Tous les droits de reproduction sont réservés, y compris pour les documents téléchargeables et les représentations iconographiques et photographiques.

L’éditeur revendique les droits d’auteur sur la totalité des textes de ce site, hormis les traductions qui cherchent à coller au plus près du texte original indiqué en référence. En revanche, l’éditeur revendique les droits liés à la traduction.

Politique de diffusion du code

L’objectif de DnC est double :
- 1. Protéger le code spécifiquement créé et la configuration du serveur OAuthSD afin de rendre plus difficile la tâche des criminels ou malveillants. Pour cela, le code figurant notamment dans les répertoires /vendor/bdegoy/oauthsd-php/src/... est crypté et n’est pas open source mais soumis à une licence particulière.
- 2. Diffuser le plus possible d’information et de code source pour permettre à quiconque d’intégrer dans ses applications la délégation d’authentification et la protection des ressources avec le serveur OAuthSD. Pour cela tout le reste du code, non présent dans les répertoires mentionnés ci-dessus, est diffusé sous licence GPLv3 ou une autre licence Open Source indiquée dans le code, notamment celui en provenance d’autre développeurs.

Cette politique s’applique aussi bien au code présent sur le serveur sous-jacent au présent site web qu’au code déployé chez les utilisateurs d’OAuthSD.

Informations sur l’éditeur

- Editeur du site : DnC société en liquidation.
- Hébergement sur serveur privé loué à OVH SAS, 2 rue Kellermann - 59100 Roubaix France.
- Responsable de la rédaction : L’éditeur du site.

Informatique et libertés

RGPD : Dans l’état actuel du développement, ce site n’enregistre aucune donnée personnelle de façon permanente (les données entrées par les auteurs et les utilisateurs sont effacées régulièrement et sont supposées fictives) et ne nécessite pas de déclaration à la CNIL. Nous n’effectuons aucun traitement sur ces données autre que les sauvegardes et ne les diffusons pas.

Cookie  : Nous souhaitons implanter un cookie de durée de vie limitée dans votre ordinateur. Ce cookie ne nous permet pas de vous identifier ; il n’enregistre aucune information personnelle ou relative à la navigation de votre ordinateur sur notre site, mais simplement un code aléatoire permettant de gérer la continuité de la navigation dans le site (session). Notez que ce type de cookie ne requiert pas votre consentement préalable, car ce n’est pas un "cookie de tracking". Nous vous informons qu’il vous appartient de vous opposer à l’enregistrement de cookies en configurant votre navigateur. Cependant, cela provoquera des dysfonctionnements.