Accueil > OpenID Connect OAuth Serveur dédié > Développer > Principes et organisation générale d’un déploiement OpenID Connect

Principes et organisation générale d’un déploiement OpenID Connect

Loin d’être une contrainte pour les différentes parties d’une grande entité, la délégation de l’authentification des utilisateurs et des applications à un serveur unique permet de déployer des applications et des serveurs de données protégées, dans des lieux différents et sous des maîtrise d’œuvre différentes, tout en assurant la sécurité des données.
L’entité coordonnant ces lieux et ces autorités devra cependant faire observer des règles pour le développement et le déploiement des applications.

Principes auxquels doivent se conformer les applications

1. Toutes les applications ( au moins celles manipulant des données confidentielles ), doivent être inscrites sur le serveur OpenID Connect de l’entité et lui déléguer l’authentification des utilisateurs.

2. Toutes les données confidentielles doivent se trouver sur des serveur de ressources ( par exemple des web-services ) appartenant à l’entité et dont l’accès est sécurisé à l’aide d’OpenID Connect.

Un tel service est d’ailleurs intégré au serveur OpenID Connect sous le nom "UserInfos".
On notera que cette obligation autorisera la bonne pratique de saisie unique des données.
Elle permettra également de tracer avec exactitude l’utilisation des données confidentielles.
Enfin, il sera possible de répondre de façon précise et exhaustive aux obligations du RGPD, notamment à une demande d’information de la part d’un utilisateur sur la détention et l’emploi de ses données personnelles.

3. On se limitera aux applications qui interrogent les serveurs de ressources confidentielles depuis un serveur privé de l’entité.
En effet, toutes les configurations d’applications, de serveurs et de ressources ne permettent pas d’identifier avec certitude une application cliente, et donc de distinguer les applications malveillantes. Sauf à admettre un risque de compromission.
Ce principe, en apparence anodin, impose en réalité une grande contrainte dans les flux d’authentification à utiliser selon la configuration des applications et des utilisateurs. Certaines configurations devront être interdites, sans céder à la commodité ou à la popularité de solutions admises par le grand public. Pour approfondir le sujet, voyez : Authentifier l’application.

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