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 :

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 (...)


OAuth 2.0 (et OpenID Connect) pour les applications natives


Nous donnons ici un exemple d’une application Windows native réalisé avec Windev qui utilise l’authentification OpenID Connect.
Contrairement à une idée trop répandue qui voudrait qu’une application native (donc sans back-end) ne puisse utiliser qu’un flux implicite, cette application met en oeuvre le flux d’autorisation avec code (Authorization Code Grant) d’OpenID Connect en passant par l’interface de bouclage (localhost).
Eléments de spécification
(traduction d’extraits de (...)


OAuth 2.0 ou OpenID Connect ?


Le serveur OAuthSD offre deux protocoles : OAuth 2.0 et OpenID Connect. Lequel utiliser ? Le deuxième, évidemment !
OAuth 2.0 n’est pas un système d’authentification (l’application cliente et l’utilisateur final ne sont pas identifiés), mais un système d’autorisation dont la sécurité souffre de l’absence de signature des jetons. Construit sur OAuth 2.0, OpenID Connect a pour but d’apporter les fonctions nécessaires à l’identification de l’utilisateur final et de l’application cliente, tout en assurant la (...)


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

Plan du site :

Présentation

Développeurs

Utilisateurs

Plus