OAuth Server dédié (OAuthSD) est un serveur d’authentification privé qui implémente OAuth 2.0 et OpenID Connect.

Qu’est-ce que OpenID Connect ?

OpenID Connect (OIDC) est en fait construit sur la base d’OAuth 2.0. OAuth 2.0 est un protocole d’autorisation largement utilisé pour sécuriser les interactions entre des applications. Il fournit un cadre pour l’autorisation, mais ne traite pas directement de l’authentification des utilisateurs. C’est là qu’OpenID Connect entre en jeu.

OpenID Connect ajoute une couche d’authentification à OAuth. Il fournit un moyen standard pour les applications de vérifier l’identité des utilisateurs. En d’autres termes, OIDC utilise OAuth 2.0 comme base pour l’authentification des utilisateurs, en ajoutant des fonctionnalités telles que la vérification de l’identité et la fourniture de jetons d’identité (ID Token.

Ainsi, OpenID Connect est pleinement compatible avec OAuth 2.0, et les deux protocoles sont souvent utilisés ensemble pour sécuriser les interactions entre les applications et les utilisateurs, en combinant l’autorisation fournie par OAuth 2.0 avec l’authentification fournie par OIDC.

Lorsqu’un utilisateur se connecte à une application cliente via OpenID Connect, il reçoit un jeton JWT (JSON Web Token) signé. Ce jeton contient des informations sur l’utilisateur, telles que son identité, ses autorisations, et les portées de l’autorisation (claims) qui définissent les droits de l’application sur les données de l’utilisateur.

OpenID Connect agit également comme un service d’inscription et de connexion unique (Single Sign-On, SSO), permettant à un utilisateur connecté à une application cliente SaaS d’être automatiquement connecté à d’autres applications pour lesquelles il a souscrit un abonnement.

En termes de sécurité, OpenID Connect protège les données sensibles des utilisateurs en fournissant des informations détaillées sur l’application et en demandant une autorisation explicite de l’utilisateur avant d’accéder à ses données personnelles. De plus, le jeton d’identité fourni par OpenID Connect est signé cryptographiquement, ce qui permet de vérifier son authenticité sans accéder au serveur d’autorisation.

En résumé, OpenID Connect offre une couche d’authentification supplémentaire à OAuth 2.0, permettant une identification sécurisée de l’utilisateur final et de l’application cliente, tout en assurant la confidentialité et la protection des données sensibles.

Sécuriser l’accès aux données avec OpenID Connect

Avec la connexion unique (Single Sign On, SSO), une entité permet aux utilisateurs de ses applications de naviguer de l’une à l’autre de façon transparente. Mais plus encore :

Avertissement : Il est important de noter que OpenID Connect, comme toute autre système d’authentification, n’assure pas la sécurité des applications ou des services de données, mais leur fournit des informations plus complètes et plus fiables sur l’utilisateur final que des méthodes d’identification plus simples. D’une part la sécurité dépendra de ce que les applications et services font de ces informations, d’autre part de leur sécurité intrinsèque ainsi que de celle du réseau.

Un serveur dédié ?

OAuthSD est conçu pour être installé dans l’infrastructure informatique d’une entreprise (on premise). Ceci est essentiel pour assurer une parfaite protection des données et des traitements en évitant de faire appel à des ressources extérieures. A la fois serveur d’authentification et d’identité, OAuthSD garantit que les données relatives aux applications, les clés cryptographiques ainsi que les identifiants et données personnelles des utilisateurs sont sous le contrôle de l’entreprise.

En pratique : le flux "autorisation avec code"

Lorsqu’une application a besoin d’authentifier l’utilisateur ( par exemple pour accéder à des données protégées ), elle s’adresse au serveur OpenID Connect. Celui-ci identifie l’application en échangeant avec elle un code d’autorisation.
Le serveur identifie l’utilisateur de l’application et détermine ses droits sur cette application. Dans certaines configurations, l’utilisateur donne son consentement pour autoriser l’application à utiliser tout ou partie de ses données personnelles.

L’application utilise ensuite le Jeton d’identité pour accéder aux ressources protégées et obtenir des données ou les modifier en fonction des droits de l’utilisateur.

La ressource protégée examine les informations transmises par le Jeton d’identité précisant l’identité de l’utilisateur, celle de l’application et les droits afférents. La ressource protégée module sa réponse ou son action en fonction de ces informations.

Diférents flux pour différentes configurations

Toutes les configurations d’applications, de serveurs et de ressources n’offrent pas le même niveau de sécurité, notamment pour authentifier l’application.

Pour une meilleure sécurité, l’application devra être de type "web" - les Progressive Web App (PWA) en sont - et mettre en œuvre le flux d’autorisation avec code ( Authorization Code Grant ).

Cependant, OpenID Connect permet de répondre à différents besoins avec différents flux d’autorisation (Grant Types). Beaucoup se sont écartés de la sécurité maximale en appliquant les flux d’OIDC aux applications mobiles et à celles des stations de travail (les applications "natives" par opposition aux applications "web"). Les PWA, qui permettent d’utiliser le flux d’autorisation avec code dans des conditions optimales de sécurité, offrent de ce fait tellement d’avantages qu’elles devraient remplacer toutes les applications natives, qu’elles soient installées sur un mobile ou sur une station de travail.

Supervision : organiser la configuration des droits

Dans une grande entité, comprenant plusieurs milliers d’utilisateurs finaux ( qu’il s’agisse du personnel ou de la clientèle ) et un grand nombre d’applications, il ne sera pas possible de centraliser la gestion des droits de chacun par rapport aux applications car il s’agira d’utilisateurs et d’applications réparties chez les membres de l’entité.

Utiliser une application spécifique
Une application spécifique devra permettre de déléguer la configuration des droits à l’échelon local. Une telle application ne fait pas partie de la spécification d’OpenID Connect. OAuthSD offre à une application externe le moyen de manipuler les données du serveur à travers une API HTTP REST + TreeQL dont l’accès est sécurisé avec ... OAuthSD.

Utiliser un système d’identification existant : LDAP etc.
Une organisation mettant en œuvre un système d’identification ou un service d’annuaire possède déjà le moyen de gérer les utilisateurs et leurs profils. OAuthSD permet d’intégrer des serveurs d’identité tiers, qu’il s’agisse de standard tels que LADP et Active Directory ( Kerberos ) ou spécifiques à une organisation (ID card, identification biométrique ...).

De plus, il est également possible d’utiliser les données d’utilisateurs d’une application développée avec un CMS tel que WordPress, SPIP ou Typo3.

Fournissant différents modules d’identification, OAuthSD ( qui est donc également un serveur d’identité ou Identity Provider ) permet de réaliser une intégration automatique de ces données par le serveur d’authentification.

Facebook, Google etc. peuvent être utilisés comme pourvoyeur d’identité, permettant à l’utilisateur de se faire reconnaître à l’aide de ses identifiants sur ces systèmes. Cependant, puisque OAuthSD offre le moyen de sanctuariser le processus d’authentification au profit de la protection des applications et des données d’une organisation, il faut aller jusqu’au bout de la démarche et sanctuariser également le processus d’identification.
Dans cette configuration, une organisation peut se réserver l’inscription des utilisateurs en suivant des procédures qui lui sont propres. Ainsi, ce n’est plus l’utilisateur qui prend l’initiative de construire son identité (ce qui lui permettrait de la falsifier).

En finir avec les mots de passe

Quelques rares systèmes d’identification permettent de ne plus utiliser de mot de passe ni de code. Plus encore, ils interdisent à l’utilisateur de s’inscrire lui-même pour fabriquer ses identifiants de connexion. De tels systèmes offrent aux entreprises le moyen de protéger les accès aux données sanctuarisées avec une grande sûreté. i-Tego NoPassConnect ou l’ Identification OpenID Connect avec ID Card en donnent des exemples opérationnels construits sur le serveur d’authentification OAuthSD.

OAuthSD et SaaS

Une application intéressante réside dans la gestion d’applications en tant que service (SaaS). Dans ce contexte, OAuthSD fournit l’authentification OIDC et transmet de façon sécurisée aux applications SaaS les paramètres relatifs aux abonnements des souscripteurs.
Le système i-Tego SaaS en donne un exemple opérationnel.

La Fondation OpenID : normalisation et certification

Le standard OpenID Connect est coordonné par les plus grandes entreprises informatiques au sein de l’OpenID Foundation. Une abondante documentation donne le cadre technique du développement d’un serveur d’authentification ( dénommé "OpenID Connect Provider" ou OP ).
Une batterie de tests, mis à disposition par la fondation, permet au serveur OAuthSD d’obtenir la Certification OpenID. Ceci garantit que le serveur d’authentification est conforme à l’état actuel de la norme. Un serveur devrait être mis à jour et soumis régulièrement à ces tests.

Quelles implications pour les applications clientes ?

OAuthSD intègre le processus d’identification de l’utilisateur. C’est non seulement une grande facilité pour le développement des applications, mais c’est aussi un avantage de sécurité.
Les applications "clientes" doivent donc pouvoir déléguer l’authentification de l’utilisateur au serveur OIDC. De plus en plus d’applications offrent cette possibilité en conformité avec le standard OpenID Connect.

Lorsque ce n’est pas le cas, un développement particulier est nécessaire pour adapter l’application. Il s’agit généralement de substituer un module OIDC au code de la connexion classique. L’adaptation est donc particulièrement aisée dans le cadre d’un développement nouveau ou d’une application "open source".

Quels enjeux pour les ressources protégées ?

La problématique du jeton porteur (Bearer Token) est bien connue : une ressource protégée qui reçoit un jeton d’identité a une bonne connaissance de l’utilisateur et de ses droits, mais doit encore s’assurer de l’identité de l’application avant d’envoyer des données à tout-va. Les spécifications d’OAuth 2.0 et d’OpenID Connect sont bien claires sur le sujet : ce n’est pas du domaine de la spécification, il faut échanger des données "dans un espace de confiance", autrement dit, dans un réseau protégé où résident les serveurs des applications, ceux des ressources protégées et le serveur d’authentification.
C’est d’ailleurs le cas de la ressource "UserInfo" spécifiée par le standard OIDC, qui, faisant partie du serveur d’authentification, offre un bon sanctuaire pour les données sensibles des utilisateurs.

Il n’y a pas de magie dans le jeton d’identité : les ressources protégées doivent être adaptées pour vérifier la validité du jeton et l’origine des demandes provenant de l’extérieur de l’espace de confiance. OAuthSD offre le moyen de valider les jetons dans le cadre des applications de type "web".

Connaître et respecter les limites d’OIDC

OpenID Connect n’est pas une panacée. D’une part la sécurité de l’authentification n’est effective que pour des configurations clients-serveur bien délimitées. D’autre part la sécurité des données dépend de ce que les ressources protégées font - ou ne font pas - de l’information fournie par le jeton d’identité.

Sous la pression du marketing, les limites d’OIDC sont parfois occultées pour affirmer la possibilité d’accéder à des ressources protégées directement depuis des applications natives (installées sur un mobile ou une station de travail). La rigueur impose de se limiter aux applications de type "web" leur adresse IP étant la preuve d’identité sur laquelle est fondé le seul flux réellement sécurisé : l’autorisation avec code. Nous donnons ici un bon exemple de sortie des limites.

i-Tego vous accompagne

Une entreprise souhaitant adopter le SSO avec OpenID Connect doit suivre trois démarches :
 Installer un serveur OpenID Connect Provider (OP),
 Adapter les applications afin qu’elles délèguent l’authentification des utilisateurs à l’OP ; les applications doivent également assurer le suivi de l’état de la session de l’utilisateur (Monitoring),
 Gérer l’inscription des utilisateurs sur l’OP, ou intégrer un système d’identification existant.

De plus, en fonction de la configuration, il faudra :
 s’assurer de la bonne capacité des ressources protégées à valider le jeton d’identité et à en vérifier l’origine.

Imprégné de la méthode et de l’éthique du consultant, i-Tego vous accompagne dans votre projet OpenID Connect pour mettre en œuvre votre propre serveur d’authentification OAuthSD. Notre maîtrise verticale du sujet nous permet d’assister les développeurs aussi bien que les chefs de projets et le maître d’ouvrage.

Enfin, si l’intervention a pour objet d’adapter OAuthSD à une configuration et à des objectifs qui vous sont propres, sachez que i-Tego transmettra à vos équipe une pleine connaissance de l’application, y compris le code source.

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