Accueil > OpenID Connect OAuth Server par DnC

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

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 :

En centralisant l’authentification des applications et des utilisateurs, un serveur OpenID Connect permet de contrôler parfaitement l’accès aux informations sensibles.

En pratique : le flux "autorisation avec code"

Lorsqu’une application a besoin d’authentifier l’utilisateur ( par exemple pour accéder à des ressources 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. L’utilisateur donne son consentement pour autoriser l’application à utiliser tout ou partie de ses données personnelles.

Il en résulte une authentification, liant en un objet infalsifiable et transmissible appelé Jeton d’Identité ( ID Token ) : l’utilisateur et ses données personnelles, l’application et les droits de l’utilisateur sur l’application ( ou vice-et-versa ).

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.

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" et mettre en œuvre le flux d’autorisation avec code ( Authorization Code Grant ).

Cependant, OpenID Connect permet de répondre à différents besoins, notamment pour les applications mobiles, avec différents flux d’autorisation (Grant Types).

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é.
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 leur profil. 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 ...).

Dans ce cas, l’API HTTP REST permet de réaliser une intégration automatique de ces données par le serveur d’authentification. On aboutit à une configuration dans laquelle le serveur d’authentification délègue l’identification de l’utilisateur à un fournisseur d’identité ( Identity Provider ).

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 Connect. 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 ?

Les applications "clientes" doivent 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".

DnC 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,
- inscrire les utilisateurs sur l’OP, ou intégrer un système d’identification existant.

DnC 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.

DnC est une entreprise indépendante imprégnée de la déontologie du consultant. En nous confiant l’installation de votre propre serveur d’authentification, vous avez la certitude que la navigation de vos clients ne sera pas exploitée à des fins publicitaires adverses. Vous pourrez également vous prévaloir d’une politique de protection de leurs données personnelles.

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

Derniers articles :

www. or not www. ?


’www.monsite.com’ et ’monsite.com’ ne sont pas les mêmes noms de domaine et, généralement, ne correspondent pas aux même serveurs Web. OAuthSD fait la différence, il ne faut donc pas mélanger les deux.
Assurer la cohérence www - non www
La cohérence doit être assurée entre :
l’enregistrement de l’URL de base au sein de l’application,
l’URL de retour de l’application enregistrée sur le serveur OIDC,
l’URL entrée dans la barre de navigation pour consulter l’application,
tous les liens internes ou (...)


Définition des scopes et généralités sur leur utilisation par les applications


La portée de l’autorisation est définie par les Scopes. C’est sans doute le point le plus ouvert du standard et donc un concept difficile à maîtriser pour le développeur d’une application utilisant OpenID Connect.
La possibilité de moduler les portées d’autorisation en fonction de l’application cliente et de l’utilisateur final est une fonctionnalité exceptionnellement intéressante d’OAuthSD.
On voit souvent en OIDC un simple SSO, mais c’est passer à côté de toute la puissance du dispositif : le jeton (...)


Monitoring de l’état de l’authentification et SLO


Le monitoring de l’état de l’authentification a pour but de synchroniser la connexion locale d’une application avec le jeton d’accès correspondant.
OAuthSD, suivant en cela OAuth 2.0, considère que l’utilisateur final est connecté à une application tant que le jeton d’accès associé est valide.
Il n’y a pas "naturellement" de relation directe entre ce jeton et l’état de connexion local d’une application. Chaque application devra donc mettre en place un monitoring, côté client, dans le but de :
surveiller (...)


| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | ... | 35 |

Plan du site :

OpenID Connect OAuth Server par DnC