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

PNG - 33.8 ko
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 Présentation
Mode d’emploi : Développeurs
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 dispositif : 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.

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.

OAuthSD s’appuie sur la librairie OAuth 2.0 Server PHP développée par Brent Shaffer.

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’authentification des connexions à vos applications, 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 :

OpenID Connect : Logout


Le point d’extrémité logout permet la déconnexion est générale (Single Logout, SLO) à partir d’une application (front channel single logout, RP generated logout etc.) : toutes les connexions d’un utilisateur sur les différentes applications sont invalidées.
Implémentation de la déconnexion
ll n’y a pas à ce jour (fin 2018) de "norme" définissant la déconnexion pour OpenID Connect. Pour s’en convaincre, il suffit de voir cet article très complet : OpenID Connect Logout et de considérer l’état d’avancement (...)


API HTTP REST


OAuthSD expose une API HTTP REST qui permet d’automatiser certaines tâches autour du serveur d’authentification. L’API s’appuie sur HTTPFoundation de Symphony. Les objets sont manipulés au format Collection+JSON ou sous un format json simple.
L’API répond à une unique action « http.api » qui va gérer trois paramètres :
- un format : c’est le nom de l’API réellement implémentée : json, collectionjson. - un type (ou une collection) : le type des données qu’on veut utiliser : auteurs, users, clients (...)


Demandes de consentement sur les portées d’autorisation (scopes)


Le règlement général sur la protection des données (RGPD) impose une gestion rigoureuse des données personnelles ce qui implique de demander à leur propriétaire l’autorisation d’y accéder. Quels sont les cas de figure à distinguer ? Comment gérer les demandes de consentement sur les portées d’autorisation à bon escient, sans lourdeur ni répétition inutile ?
Demande de consentement : différents cas de figure
Dès leur origine, OAuth et OpenID Connect ont été pensés pour protéger les données sensibles (...)


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

Plan du site :

Présentation

Développeurs

Utilisateurs

Plus