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 .