SaaS et OIDC : comment ça marche ?

, par WM i-Tego

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

Nous développons 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.

En développant de nombreuses applications publiques nous acquérons un retour d’expérience indispensable pour la qualité de notre offre de sécurité fondée sur notre serveur d’authentification.

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 supports 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 O-DGuide 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 connexion 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.