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.

Avec OAuthSD, les mots de passe ne peuvent être interceptés au moment de leur saisie, ne circulent pas sur Internet, ne sont enregistrés nulle part ! Et les données personnelles de vos prospects sont stockées dans un espace protégé.

Architecture d’OAuth Server by DnC

Avertissement : Ce site web implémente un démonstrateur d’OAuthSD ; le serveur peut être indisponible et les données enregistrées effacées à tout moment.
Si vous êtes intéressé par une version de production de OAuthSD, sur un serveur privé de votre propriété, contactez DnC

Ce dont il s’agit : définition officielle de OAuth 2.0 commentée et Découvrir
Mode d’emploi : Développer
Mise en œuvre : Gérer

On voit souvent en OpenID Connect un simple système de connexion unique (Single Sign On, SSO), mais c’est passer à côté de toute la puissance du procédé : le jeton d’identité JWT regroupe, de façon indissociable et infalsifiable, l’identité de l’utilisateur final, celle de l’application cliente et les portées d’autorisation ; voyez : Définition des scopes et généralités sur leur utilisation par les applications.

Dès l’origine, OAuth et OpenID Connect ont été pensés pour protéger les données sensibles appartenant à l’utilisateur final, à qui on demande l’autorisation d’y accéder. Le vocabulaire utilisé et les exemples donnés dans les spécifications sont fortement orientés par cette vision.

Cependant, avec un peu de recul, on voit que l’on est en présence d’un ensemble de techniques qui permettent de faire aussi l’inverse : s’assurer que l’utilisateur final est bien celui qu’il prétend être et autoriser son accès à des ressources protégées ou des applications qui contiennent des données sensibles, lui appartenant ou non.

Vous voulez entrer rapidement dans le vif du sujet ? Lisez ces articles : OpenID Connect : Lier une application cliente au serveur OAuthSD et Exemples complets du flux d’Autorisation.

Pour revenir à SSO (Single Sign ON), OAuthSD vous offre le meilleur : pour assurer non seulement l’inscription unique, mais encore la connexion unique (Single Login Identification, SLI) sur de multiples applications, la ré-authentification silencieuse (Silent Re-Authentication, SRA) et la déconnexion unique (Single Login Out, SLO). Voyez : SLI, SLO et SRA sont dans un bateau : OAuthSD. Alors que la plupart des implémentations exigent des développements du côté des applications clientes, OAUthSD vous offre ces fonctionnalités sans aucune modification de celles-ci. Tout ceci mis bout à bout permet d’assurer la visualisation et le management de la session OpenID Connect côté client. Actuellement, nous nous attachons à renforcer la sécurité de l’identification avec la Validation en 2 étapes (Two Factor Authentication, 2FA) .

OAuthSD s’appuie sur la librairie OAuth 2.0 Server PHP développée par Brent Shaffer. Un travail notable de DnC a consisté à encapsuler les points d’entrée de cette API dans une couche de sécurité, avec des fonctionnalités supplémentaires. Le développement respecte les spécifications, voyez : OAuthSD vers la Certification OpenID ®.

Un serveur d’authentification privé s’adresse aux développeurs et aux propriétaires de sites Web désireux de se protéger de la concurrence résultant du ciblage comportemental et du profilage de leurs clients et, par la même occasion, d’offrir à ces clients de ne pas confier aveuglément leurs données personnelles. C’est un excellent moyen de se conformer au RGPD.

DnC est une entreprise indépendante qui a pour politique de ne jamais exploiter ni communiquer les données collectées. 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.

Derniers articles :

Vérification de l’origine de la requête reçue par un serveur de ressource


La transmission de jetons à des serveurs de ressource (RS) implique que ces derniers soient réceptifs à des jetons de toute provenance. Cela présente une opportunité pour un attaquant (une application étrangère) d’exploiter un jeton compromis ou volé.
Une fois de plus, l’analyse montre que nous ne sommes en mesure d’assurer la sécurité des données que dans le cas du flux "Authorization Code"
Considération sur la sécurité de la transmission des jetons aux serveurs de ressources
La proposition de (...)


Authentification de l’utilisateur final


L’identification est la partie de l’authentification au cours de laquelle l’utilisateur final s’identifie ou est identifié. OAuthSD offre tout ce qu’il faut pour traiter l’identification (login/mot de passe, identification à deux facteurs) ou peut déléguer cette identification à un système pourvoyeur d’identité tiers (Identity Provider).
Systèmes d’identification intégrés à OAuthSD
OAuthSD distingue les fournisseurs d’identité primaire et, si l’identification à deux facteurs (2FA) est activée, les (...)


Ré-authentification silencieuse du sujet avec l’ID Token


L’authentification du sujet (subject, sub) avec l’ID Token est une option du flux de code OpenID Connect Authorization. Pour remplir la certification OpenID Connect, il est nécessaire de terminer le test "OP-Req-id_token_hint". La bibliothèque oauth2-server-php de Brent Shaffer ne traite pas id_token_hint. OAuthSD devra donc s’en occuper.
Le cas d’utilisation consiste à appeler Authorize à l’aide de prompt = ’none’ et à transmettre l’ID Token par le paramètre id_token_hint.
La spécification stipule : (...)


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

Plan du site :

OpenID Connect OAuth Server par DnC