OpenID Connect OAuth Server dédié

Q : le flux d'autorisation est-il aussi bon pour le natif/mobile ?

DnC — 2024-03-14T09:55:29Z

Bénéficiant des travaux de Bertrand Degoy, i-Tego maîtrise l'IA générative à partir des données de votre entreprise. Nous pouvons ainsi vous fournir des outils de recherche avancés sur un très grand nombre de documents de tout type, explorer vos bases de données, vos e-mails etc. Le tout avec une traduction automatique !


i-Tego chat bot: i-Tego offers businesses a chatbot whose document database includes their own data : https://chat.i-tego.com/

Voici l'exemple d'un chat exploitant la documentation d'i-Tego :

Q:le flux d'autorisation est-il aussi bon pour les applications natives/mobiles que pour les applications Web ?

R : Le flux d'autorisation est généralement considéré comme plus adapté pour les applications Web que pour les applications natives ou mobiles. En effet, les applications Web sont plus faciles à sécuriser car elles fonctionnent dans un environnement contrôlé et dépendent d'une connexion permanente au serveur, ce qui facilite l'utilisation du flux "Authorization Code" pour protéger les données.

En revanche, les applications natives ou mobiles peuvent rencontrer des difficultés avec le flux d'autorisation, notamment en ce qui concerne l'authentification de l'application elle-même. Les méthodes de sécurité telles que le "Proof Key for Code Exchange" ou le "Proof of Possession" peuvent renforcer la sécurité des jetons émis, mais ne permettent pas toujours d'authentifier pleinement une application sans back-end.

Il est donc recommandé d'utiliser le flux de code d'autorisation pour les applications natives ou mobiles, mais il est important de prendre en compte les spécificités de ces types d'applications en matière de sécurité.

Sources :

Document "Authentifier l'application - OpenID Connect OAuth Server dédié" (pages 8, 9, 14, 15)"

Il est important de noter que la question à une réponse libellée en français est fondée sur des documents différents que celle répondant à une question libellée en anglais. En effet, la base documentaire fournie par i-Tego au chatbot est principalement en langue française. Dans le choix des sources, la priorité est donnée à la langue de la question.

L'authentification dans le cadre de l'IIoT

DnC — 2022-10-23T10:00:38Z

Assurer la sécurité de la transmission des données entre les applications et les objets connectés de l'Industrie du Futur :
Outre la sécurisation des données en provenance des capteurs, l'étude et le démonstrateur du projet "AuthSec" seront particulièrement orientés vers la sécurité des ordres passés aux actionneurs en vue d'éviter les dysfonctionnements et les accidents.
Deux techniques seront combinées : l'authentification de bout en bout, au niveau applicatif, pour compléter la sécurité du niveau réseau ; des algorithmes basés sur l'apprentissage profond pour détecter et bloquer les commandes à risque.
Cette démarche s'inscrit dans une réflexion sur les conditions de la Cyber-résilience de l'Usine du Futur.

Le contexte dans lequel se conçoit la sécurité de l'Usine du Futur

Une ouverture encore mal maîtrisée

S'agissant de la sécurité des applications informatiques des entreprises le modèle initial consistait (et consiste toujours pour beaucoup) à sanctuariser les données et les traitements dans un réseau local isolé des services extérieurs et auquel seuls les utilisateurs du site pouvaient accéder. Ce modèle radicalement efficace est devenu inapplicable compte tenu de l'intérêt que pourraient présenter certains services externes pour une application particulière et de la nécessité d'ouvrir l'accès au réseau à des utilisateurs extérieurs : collaborateurs, clients, usagers. Il paraît inutile de justifier plus avant ce qui est maintenant une évidence.
S'agissant des collaborateurs hors site, une première ouverture a consisté à permettre l'accès à des utilisateurs ou des applications depuis le réseau Internet à l'aide de pare-feu, de tunnels ou d'une console distante, l'accès étant contrôlé en une seule fois à l'entrée. Le collaborateur distant se trouve alors dans la même situation que s'il se trouvait sur le site de l'entreprise. Bien que ce modèle périmétrique soit à l'origine de nombreux et graves problèmes de sécurité, sa simplicité conceptuelle, son application dès les débuts de l'informatique et sa facilité de mise en œuvre en font une solution trop largement adoptée.
Parallèlement, le besoin s'est fait sentir de mettre à la disposition du public des applications leur permettant d'interagir avec les données de l'entreprise ou de l'administration. C'est tout naturellement que les applications Web sont nées. L'utilisateur distant n'accède plus au réseau avec des outils omnipotents, mais au niveau applicatif, de son navigateur au « site web », c'est à dire à une application résidant sur un serveur. Une authentification de niveau applicatif, gérée par l'application elle même, permet de limiter son accès aux seuls traitement et données qui sont autorisés à l'utilisateur qui s'y connecte.
On aurait pensé que les applications Web auraient été développées dans le même temps pour permettre le télétravail, mais cela n'a pas été anticipé par les grandes entreprises restées positionnées sur le travail sur site, ou accoutumées aux tunnels ( établissant des réseaux virtuels privés ou virtual private network, ou tunnel VPN ) pour le travail de site à site, et qui ont naturellement adopté le modèle périmétrique pour le télétravail.
Outre les facteurs historiques et culturels, il faut reconnaître le frein que représente la nécessité de modifier les applications « natives » pour en faire des applications web capables d'authentification, avec des délais et des coûts considérés comme improductifs. Face à l'urgence d'organiser le télétravail, un marketing opportuniste a fait admettre le tunnel VPN comme la panacée, alors que cela consiste à étendre le réseau de l'entreprise aux réseau locaux des box familiales au domicile des employés, avec les risques que l'on imagine - eh bien non, justement, on ne l'imagine pas. Alors que la sécurité des tunnels de site à site avait soigneusement été établie, la précipitation et les mauvaises pratiques prévalent dans le cadre du télétravail.

La tentation du Cloud

Une certaine image de l'Usine du Futur est aujourd'hui déterminée par des facteurs qui lui sont largement étrangers :
la domination du marché grand public sur le marché professionnel, imposant ses produits et ses schémas mentaux ainsi que ses méthodes de marketing,
le besoin de connexion à distance pour le télétravail, malheureusement fondé sur des réseaux conçus pour le grand public et des équipements domestiques,
le désir de mobilité, recherche quasi ludique d'une facilité de connexion permanente, sans distinction de moyens, de techniques ou de comportement entre l'espace professionnel et la vie extérieure,
l'approche commerciale des entreprise de services du numérique qui, à la suite des GAFAMs ayant largement promu la technique d'externalisation des services dans le Cloud, proposent de plus en plus des plateformes en tant que service (PaaS) qui leur sont particulièrement avantageuses, en évitant de trop mentionner ni traiter les problèmes de sécurité que cela implique.

A ces facteurs extérieurs, on pourrait ajouter deux tendances bien ancrées dans l'esprit de certains dirigeants et qui devraient pourtant appartenir au passé :
l'externalisation de fonctions relevant de compétences considérées comme inaccessibles ou rangées par principe hors du « cœur de métier »,
l'incompréhension des techniques de sécurité, la confiance excessive, la négligence au nom de la rapidité de développement et de la productivité, ou encore le classement des investissements de sécurité dans les charges improductives,
la crainte de se voir reprocher des choix technologiques hasardeux plutôt que le maintien de techniques dont la fiabilité serait justifiée par leur ancienneté et leur large adoption,
le sentiment de propriété des ITs sur la sécurité, qui - de leur point de vue - devrait être de leur seule compétence et donc appliquée exclusivement au niveau réseau, faussement en concurrence avec une sécurité au niveau applicatif présentée comme alternative et non comme complémentaire.

Ainsi, il est donné aux public et aux chefs d'entreprise une vision de l'Usine du Futur dans laquelle tout est connecté à tout, sur le modèle applicable au grand public.
L'une des implications les plus lourdes pour la sécurité des réseaux est la multiplication des connexions extérieures non seulement à la périphérie des réseaux, mais encore dans leur profondeur.
Or, un grand désordre existe dans la sécurité des réseaux, à l'origine de nombreux accidents de sécurité ou de sûreté de fonctionnement. Pour l'Usine du Futur, de tels accidents sont inacceptables car ils pourront se traduire en perte de propriété industrielle et en arrêt de production.

Le modèle « Jéricho »

Depuis longtemps déjà les entreprises ont ouvert l'accès à leur réseau en contrôlant l'accès à leur périmétrie. Cependant, de multiples attaques aux conséquences graves ont démontré la faillite du modèle périmétrique.
Ce constat a été fait il y a de nombreuses années déjà. En 2004, le Jericho Forum introduisait le concept de dépérimétrisation, une stratégie de défense qui consiste en un système de sécurité segmenté et multicouche basé sur le chiffrement et l'authentification, incluant les ressources hors site. Plus proche de nous, le concept de « zéro confiance à l'accès réseau » ( Zero Trust Network Access, ZTNA ) en reprend quelques principes, sous une forme plus médiatique, mettant l'accent sur l'authentification.
Selon le modèle « Jéricho », la sécurité est appliquée là où se trouvent les données et les traitements à protéger, c'est à dire au niveau applicatif de chaque service ( applications, services Web, machines, objets connectés etc. ). C'est bien ce qu'applique l'OTAN avec le principe de protection "Data-centric Security (DCS) :" rather than focusing on network perimeter defence focuses on securing access to the data itself. [1]".

Il ne faut pas concevoir l'authentification au niveau applicatif comme un moyen de suppléer à une mauvaise sécurité du réseau. Assurer la sécurité à travers les applications web exige que l'on ne puisse pas accéder directement aux données au niveau réseau. Le principe sera d'isoler les services dans un périmètre réduit ( résultant de la segmentation multicouche ), bien sécurisé au niveau réseau et accessibles seulement au niveau applicatif avec authentification. En particulier, cela exige de ne pas permettre l'accès direct au gestionnaire de données, ce qui implique que toute opération administrative devrait être effectuée à partir d'une connexion locale. L'idéal serait de n'ouvrir au niveau réseau que les ports strictement nécessaires aux protocoles de la couche ISO n° 5, à la limite seulement 443 pour HTTP et MQTT sécurisés par TLS.

L'Usine du Futur sera sécurisée ou ne sera pas

Mais de quoi parle-t-on ? L'usine du Futur n'existe-t-elle pas déjà ? Les chaînes de construction automobile ne sont-elles pas déjà totalement informatisées et robotisées ? Le système CATIA ne permet-il pas de concevoir, développer et réaliser de nouveaux produits, son succès mondial témoignant de sa sécurité ? A l'évidence les grandes entreprises ont maîtrisé le sujet. Il est certain qu'elles ne sont pas sensibles à l'image médiatique, ayant les moyens d'étude nécessaires à la conduite de leur évolution.
Ce sont les TPE/PME qui se trouvent à la merci du tapage médiatique – y compris sur les revues « professionnelles » - et la cible de démarches commerciales mal adaptées. Ce sont elles qui doivent être accompagnées au cours de leur création ou de leur transformation.

Sûreté de fonctionnement, Contrôle des accès et Sécurité des données

Si on se réfère aux offres d'un marketing dominant, il faut s'en remettre à l'Internet pour délocaliser les données et les traitements dans le Cloud. Les données font alors le tour du monde : où et par qui sont-elles traitées, et par quelles applications ? Où sont-elles sauvegardées ? Comment sont-elles protégées ?
Avant de répondre à ces questions, il faut définir la notion de Cloud .

Cloud ou Cloud privé ?

Il convient tout d'abord de distinguer :
La définition initiale du Cloud qui est née de la virtualisation des traitements et du stockage des données chez les grands hébergeurs, permettant de mettre à disposition des abonnés des ressources virtuelles. Dans cette configuration, il s'agit de "Cloud privé" dont l'accès et la configuration sont sous le contrôle de l'entreprise ( ou a minima d'un sous-traitant de confiance ). Des offres telles que IBM Cloud, Amazone AWS ou OVH Private Cloud offrent les garanties de propriété attendues par les entreprises.
Une externalisation générale des traitements et des données confiés à des sous-traitants extérieurs à l'entreprise, qui eux-mêmes peuvent faire appel à d'autres intervenants sans que ce soit identifiable et contrôlable par l'entreprise, ni même stable dans le temps. Parmi ces offres, il existe des services de données ou de traitement sans doute très commodes, mais dont la qualité et la pérennité est incontrôlable. L'opacité de cette configuration a conduit au terme de nuage, qui par un effet de sablier a été érigé au niveau d'un principe largement véhiculé par les médias.

Un enjeu de sécurité

Avec des données et des traitements distribués dans un tel Cloud, tous les enjeux de sécurité se situent hors de la portée de l'entreprise :
• Sécurité des accès : l'authentification des utilisateurs et des applications est déléguée hors du contrôle de l'entreprise.
• Sécurité des données des utilisateurs du public : peut-on réellement appliquer le RGPD ?
• Sécurité des données de l'entreprise non garantie, exposant à l'espionnage industriel et à la contrefaçon.
• Sauvegarde des données de l'entreprise : il lui est impossible de s'en assurer, au risque d'une perte totale.
De plus dans une telle configuration, la surface d'attaque est indéfinie et probablement immense.

Un enjeu de sûreté, de rapidité et de continuité de fonctionnement

• Sûreté de fonctionnement : trop de composants hors du champ d'action de l'entreprise, totalement contraire à toute démarche de qualité.
• Rapidité : les processus industriels sont quasi temps réel. Des interruptions de service de quelques secondes, ou des temps de réponse présentant de temps en temps des valeurs inacceptables, peuvent déstabiliser une chaîne de production, voire provoquer son arrêt.
• Continuité : la disponibilité des réseaux est également en question, en commençant par le raccordement de l'entreprise au réseau. Certes, le maillage de l'Internet assure la sûreté du transport à longue distance, mais le même problème de disponibilité se retrouve du côté des fournisseurs, à moins qu'il s'agisse de grands hébergeurs.

Pas totalement convaincu ? Voyez : David Heinemmeier Hansson : « Why we are leaving the cloud ».

"On premise" ou cloud privé ?

L'analyse ci-dessus conduit à :
ne pas tout mettre dans un Cloud mal défini et hors contrôle, mais s'en tenir aux Cloud privés des grands hébergeurs, voire à un datacenter de proximité ( ou Cloud de proximité ).
envisager la technique du "serveur edge" pour réduire la surface d'attaque, réduire le temps de réponse, contribuer à la résilience et conforter la souveraineté.
identifier les tâches sensibles aux délais de transmission ou d'interruption de service (voire aux attaques de déni de service) et les assurer localement (résilience),
veiller à confier les tâches sensibles à des sous-traitants proches.

Une approche radicale de la résilience conduirait à distinguer un ensemble indépendant de machines, d'applications de contrôle et de gestion quotidienne de la production capable d'assurer la production sans connexion extérieure.

Quel choix pour un serveur d'authentification ?

Le principe de l'authentification avec OpenID Connect est que les applications délèguent le processus au serveur, le dialogue d'identification étant effectué directement entre l'utilisateur et le serveur, sans intervention de l'application. Il en résulte que toutes les données relatives à l'authentification des applications et des utilisateurs, leurs données personnelles et les données cryptographiques sont situées sur le serveur.

De plus, les échanges entre les différents pôles pour l'authentification se produisent très fréquemment au rythme des échanges de données et doivent être extrêmement rapides. Quelques dizaines de millisecondes est l'ordre de grandeur visé. Le serveur est le coopérant obligé de toute transaction sécurisée. Il doit donc être parfaitement disponible.

Enfin, la plus dangereuse des attaques serait le détournement du trafic vers un serveur pirate. Pour se prémunir contre tout détournement d'adresse Internet (IP) il convient de situer le serveur d'authentification dans un "système autonome" cohérent avec le réseau de l'entreprise. Une solution radicale serait de placer le serveur dans le réseau de l'entreprise. Sinon, il convient de choisir un ensemble de réseaux gérés par une même entité (fournisseur de service, hébergeurs, intermédiaires techniques, etc.).

La sécurité et la sûreté imposent donc de situer le serveur d'authentification "à proximité" du réseau de l'entreprise.

[1] Konrad Wrona "Towards Data-centric Security for NATO Operations" DIGILIENCE 2020

i-Tego vous offre plusieurs centaines de pages...

DnC — 2021-08-04T15:35:17Z

En relation avec i-Tego, nous vous offrons plusieurs centaines de pages de documentation et de code sur l'authentification avec OpenID Connect et ses applications.

Vous êtes ici au niveau le plus détaillé.

Les documents sont distribués sur trois niveaux :

Le site i-Tego.com présente rapidement les concepts généraux et fournit des entrées vers les points essentiels de la documentation.
i-Tego SAS : la documentation offre un premier niveau de détail déjà très suffisant pour une bonne connaissance d'OpenID Connect et des opportunités de travail avec l'équipe i-Tego. De nombreux liens en font un guide pour aborder le niveau de détail suivant.

Peut-être pourriez-vous commencer ici ?

.
le présent site OpenID Connect OAuth Serveur Dédié s'adresse aux développeurs. Avec quelques centaines de pages (dont du code), le site leur permettra d'acquérir une connaissance approfondie d'OpenID Connect et du serveur OAuthSD développé par DnC.

En savoir plus sur l'accompagnement proposé par i-Tego : authentification des utilisateurs et des applications avec OpenID Connect.

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

DnC — 2021-07-29T16:44:00Z

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 i-Tego 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, sans oublier les sites support tels que la plateforme CRM et les sites de communauté. 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 i-Tego 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 .

Le flux des échanges est le suivant :
1 : l'utilisateur s'inscrit sur le système SaaS et souscrit un abonnement.
2 : Il se connecte depuis une application cliente du système SaaS.
3 : Le serveur d'authentification adresse à l'application cliente un jeton JWT signé dont la charge utile a été complétée avec :
les données relatives à l'abonnement, en particulier sa date de fin,
les droits de l'utilisateur sur l'application,
les options souscrites.

Rappelons que, selon le protocole OpenID Connect :
le jeton adresse également les portées de l'autorisation (claims) donnant les droits de l'application sur les données de l'utilisateur.
le serveur d'authentification agit comme un service d'inscription et de connection unique (Single Sign On, SSO) . Ainsi, l'utilisateur connecté à une application cliente SaaS est également connecté aux autres applications pour lesquelles il a souscrit un abonnement

Notre offre de services

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 ?

OAuthSD V2

DnC — 2021-04-25T08:39:00Z

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. Il fallait également intégrer au contrôleur Authorize des méthodes d'identification avancées multifacteurs.

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é signés (JWS) et meme des jetons encryptés (JWE)..

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). Cela répond à une recommandation de L'ANSSI.

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.

OpenID Connect et OAuth 2.0 : Les points d'extrémité d'OAuthSD

DnC — 2021-04-21T13:54:58Z

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.

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

[2] Aussi connu sous le nom de Resource Owner Endpoint

En quoi OIDC contribue-t-il à l'approche ZTNA ?

DnC — 2020-03-27T08:18:52Z

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

Est-ce vraiment nouveau ? Est-ce vraiment suffisant ?

De façon générale, on assure une sécurité périmétrique à l'aide d'un pare-feu et de mesures de protection afin d'empêcher les intrusions. Constatant l'absence de mesures de protection lorsque les intrus parviennent à franchir le périmètre, ZTNA semble proposer d'accepter le réseau tel qu'il est et de reporter la défense au niveau applicatif. Ce serait une erreur de négliger le réseau : par exemple, si l'accès aux fonctionnalités d'administration de la base de données (avec une console SSH) est mal protégé, il ne sera pas suffisant de protéger l'accès à l'application.
En 2004, le Jericho Forum introduisait le concept de dépérimétrisation, une stratégie de sécurité qui consiste à compléter la « limite » de sécurité standard séparant un réseau de l'Internet et à créer à la place un système de sécurité segmenté et multicouche basé sur le chiffrement et l'authentification.

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 :

Le principe ZTNA nous invite à compléter les protections du niveau réseau (VPN, firewall, proxy) en authentifiant les applications et les personnes. Le principe de dépérimétrisation nous invite à appliquer les barrières dans la profondeur du réseau et à chiffrer au niveau applicatif.

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.

Dans cette perspective, l'effort de développement portera sur :
l'identification physique de la machine de l'utilisateur au niveau paquet (adresse IP) et trame (adresse MAC),
le contrôle d'intégrité de l'agent utilisateur et de son hôte.

Une solution consisterait à développer un agent utilisateur spécifique qui, vu d'OIDC comme une application, relèverait des informations physiques et les communiquerait au serveur OAuthSD. Cette application devrait effectuer des contrôle d'intégrité et de non-intrusion, par exemple en remontant des données recueillies sur les logiciels de sécurité résidant sur l'hôte.

S'agissant de l'application, une piste se situe du côté des Progressive Web Applications (PWA) dont il parait possible de contrôler l'intégrité.

Identification de l'utilisateur final

DnC — 2020-02-03T08:13:00Z

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.

OpenID Connect et OAuth 2.0 : Synthèse des flux d'autorisation (Grant Type)

DnC — 2019-04-06T17:58:00Z

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'extrémité 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

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

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

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

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

[5] Ou "Resource Owner Password Credentials Grant Type". Nous citons ce flux, et OAuthSD le met en œuvre, 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 impersonnalisation (sur ce sujet, voir : https://www.scottbrady91.com/OAuth/..., nous recommandons donc de ne pas l'utiliser.

[6] Cela 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.

[7] C'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.

OAuth 2.0 ou OpenID Connect ?

DnC — 2019-01-11T07:40:00Z

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.

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

[2] C'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.

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

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

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