La transmission aux ressources protégées de données certifiées sur l’utilisateur et sur l’application vise plusieurs objectifs :

– S’assurer que seules les données nécessaires et autorisées sont transmises, et qu’elles ne le sont pas à un intrus. Dans cette optique on parlera des privilèges de l’utilisateur sur l’application. Il s’agit par exemple de rôles tels que ’administrateur’, ’rédacteur’, ’visiteur’ etc.

– Paramétrer les fonctionnalités de l’application en fonction des droits acquis par l’utilisateur à un instant T. Dans cette optique on parlera des droits de l’utilisateur sur l’application. Un bon exemple réside dans la transmission à une application distribuée en mode SaaS de l’état d’un abonnement (à jour de cotisation ou non, etc.) et des options souscrites.

– Identifier l’application pour s’assurer que l’on n’adresse pas des données protégées à un malware.

Avec OpenID Connect, l’authentification résulte en un objet transmissible appelé Jeton d’Identité ( ID Token ) qui lie de façon infalsifiable : l’utilisateur et ses données personnelles, l’identité de l’application et les privilèges/droits de l’utilisateur sur celle-ci (ou vice-et-versa).

Il est important de noter que la sécurité dépendra de ce que les ressources protégées (applications et services) font de ces informations.

OAuthSD, tout en étant dans le standard OpenID Connect, apporte des fonctionnalités déterminantes :

L’intégration d’un système d’identification existant

OAuthSD peut utiliser un système d’identification tiers comme un lecteur de carte ou un annuaire tel que LDAP / Active Directory / Kerberos et intégrer au jeton d’identité des données issues de ces systèmes.

L’authentification avec OAuthSD ne nécessite alors aucun changement dans les techniques d’administration ni dans la configuration des utilisateurs, le serveur d’authentification utilisant le service d’annuaire existant.

La transmission de données supplémentaires

OAuthSD permet d’incorporer au jeton d’Identité des déclarations supplémentaires. La structure modulaire du code permet d’adapter rapidement le serveur pour intégrer des données de l’entreprise. Une API REST peut également être utilisée à cette fin.
Si le jeton d’identité est signé (JWS) afin de certifier l’intégrité des données transmises, il n’est en revanche pas crypté. OAuthSD fournit le code nécessaire pour produire un jeton crypté (JWE).

L’identification de l’application

OpenID Connect n’est en mesure d’assurer pleinement la sécurité des données que dans le cas du flux "Authorization Code" pour des applications de type web dites "avec back-end".

OAuthSD offre aux ressources protégées deux moyens de vérifier la légitimité d’une application présentant le jeton d’identité en se fondant sur l’IP de l’origine :
– par introspection avec l’IP du demandeur,
– avec les déclarations supplémentaires du jeton d’identité ’cip_hash’ ou ’requester_ip’.

S’agissant des applications de mobile ou de station de travail, dites "sans back-end", i-Tego travaille aux moyens de les identifier et de s’assurer de leur intégrité.

Une application exemplaire : i-Tego SaaS

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.