En quelques mots pour les utilisateurs : Après une unique procédure d’authentification, vous serez automatiquement connecté aux applications sans qu’elles puissent accéder à vos identifiants personnels (login et mot de passe). Avec OAuth by DnC, votre mot de passe ne peut être intercepté au moment de sa saisie, ne circule pas sur Internet, n’est enregistré nulle part !

En quelques mots pour les développeurs : un serveur OAuth 2.0 + OpenID Connect permet de déléguer à un système indépendant l’authentification des utilisateurs finaux afin qu’ils puissent naviguer en toute sécurité dans vos applications ; vous accorderez une grande confiance dans l’identité réelle des utilisateurs ; vous pourrez également authentifier l’accès à des ressources réparties (par exemple dans le Cloud) dans ce qui peut être assimilé à une session virtuelle, identifiée par le jeton d’identité (ID Token).

Pourquoi un serveur d’authentification ?

  publie le par DnC

Qui a besoin d’un serveur d’authentification ?

OAuth Serveur by DnC est construit sur l’architecture OAuth 2.0. Voici un exemple d’application donné page 5 de la spécification RFC 6749 :

Par exemple, une utilisatrice finale (Propriétaire de la ressource) peut accorder à un service d’impression (Client) l’accès à ses photos protégées stockées dans un service de partage de photos (serveur de ressource), sans partager son nom d’utilisateur et son mot de passe avec le service d’impression. Au lieu de cela, elle s’authentifie directement auprès d’un serveur approuvé par le service de partage de photos (Serveur d’autorisation), qui émet les accréditations (jeton d’accès) spécifiques de la délégation du service d’impression.

OAuth permettant de réaliser une authentification à l’extérieur des applications, il en résulte deux avantages :
- les informations de l’utilisateur restent inconnues des applications, et en particulier des opérateurs de tracking,
- la navigation au sein d’une application faite de multiples composants et l’échange de données entre ces composants se trouvent sécurisés par un processus d’autorisation unique.

De plus, au moment de la demande de connexion à une application cliente, OAuth fournit à l’utilisateur des informations sur l’auteur de l’application et sur les données personnelles auxquelles l’application souhaite accéder. Ainsi, l’utilisateur accède à l’application (ou non) en pleine connaissance de cause. OAuth inverse donc le paradigme de la connexion : au lieu de demander à l’internaute (l’utilisateur final) un login et un mot de passe sans aucune justification ni garantie sur les traitements qui vont suivre, OAuth présente une demande d’autorisation justifiée par des informations pertinentes sur l’application et sur ce qu’il adviendra des données personnelles de l’internaute.

Ainsi, un serveur OAuth privé apporte une solution de sécurisation 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.

De quoi s’agit-il exactement ?

Voici la traduction du résumé donné en tête de la Spécification OAuth 2.0 (RFC 6749) :

L’architecture d’autorisation OAuth 2.0 permet à une application tierce d’obtenir un accès limité à un service HTTP, soit au nom d’un propriétaire de ressource en orchestrant une interaction d’approbation entre le propriétaire de la ressource et le service HTTP, soit en autorisant l’application tierce à obtenir l’accès en son propre nom.

Analysons ce texte :

"architecture" : bien que OAuth 2.0 fournisse des fonctionnalités d’un haut niveau d’abstraction, différents protocoles l’incorporeront pour répondre à un cas de figure particulier. C’est le cas de OpenID Connect, qui étend OAuth pour fournir un protocole d’authentification, permettant aux serveur de ressources d’agir selon l’identité de l’utilisateur final. C’est également le cas d’ OAuth Server by DnC (OAuthSD) qui offre un protocole de vérification de jetons d’accès ainsi qu’un service de session inter-applications.

"application tierce" : cela sous-entend que OAuth définit trois composants : l’application cliente qui accède à un serveur de ressource par l’intermédiaire d’un serveur d’autorisation, ce dernier étant physiquement distinct des deux autres composants. Notons que l’on devrait parler d’"applications tierces" car OAuth est très efficace pour contrôler les accès aux données d’un client avec différents serveurs de ressources, ce qui fait qu’OAuth est un outil indispensable pour sécuriser les échanges de données d’applications réparties dans le Cloud.

"accès limité" : c’est une allusion au mécanisme des scopes permettant de préciser l’étendue des données accessibles et les actions autorisées sur ces données.

"un service HTTP" : Cette spécification est conçue pour être utilisée avec HTTP (RFC2616). L’utilisation d’OAuth sur tout protocole autre que HTTP est hors du sujet. Cela en fait un système particulièrement aisé à mettre en œuvre dans le cadre d’une application Web faisant appel à des ressources HTTP REST.

"soit en autorisant l’application tierce à obtenir l’accès en son propre nom" : cela démontre que OAuth n’est pas limité à offrir aux utilisateurs finaux le moyen de contrôler l’accès à leur données personnelles. OAuth a de nombreuses applications pour le contrôle des échanges entre applications et serveurs de données, ce qui prend toute sa signification dans le cas d’applications et de données réparties dans le Cloud.

Cette dernière observation est capitale pour saisir toute l’étendue des applications possibles. 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.

OAuth 2.0 est-il un système d’authentification ?

L’authentification suppose que l’application protégée, qui reçoit une autorisation de délivrer les informations à l’application cliente, puisse identifier l’utilisateur final qui est à l’origine de l’autorisation.
OAuth 2.0 fournit une excellente base, mais qui doit être complétée pour assurer l’authentification.

OpenID Connect

OpenID Connect est une couche d’authentification construite sur OAuth 2.0. Le serveur d’autorisation (ou "fournisseur OpenID" dans ce cas) contient des informations sur une personne. OAuth est utilisé pour protéger ces informations, permettant à une application tierce (client) d’y accéder au nom d’une personne. Pour autoriser la diffusion d’informations, la personne est authentifiée et le Fournisseur OpenID fournit au client des détails notamment sur l’identité de la personne et le moment de l’authentification.

En quoi OAuth améliore la sécurité des applications ?

En soi, OAuth protège efficacement les identifiants d’accès (login, mot de passe etc.). Cela constitue un énorme avantage de sécurité en assurant que ces données ne seront jamais compromises et détournées pour accéder à des données protégées.

S’agissant de l’accès aux serveurs de ressources protégées (par exemple un web service), OpenID Connect fournit un jeton d’identité dans lequel l’identité de l’application cliente, celle de l’utilisateur et les autorisation d’accès sont liées par une signature cryptographique qui pourra être validée par le serveur de resource destinataire.

Un travail important reste à faire du côté des applications

OAuth 2.0 ne définit pas comment un serveur de ressources protégées doit vérifier la validité du jeton d’accès ni comment interpréter l’étendue des autorisations (scopes). De plus, ni OAuth, ni OpenID Connect, ni finalement OAuth Server by DnC ne définissent comment doit être exploitée la fonction d’authentification du côté du serveur de ressources.

Pour se convaincre de la réalité du problème, écoutons Eran Hammer, un des spécialistes d’OIDC : "Le fait que ce soit hors du champ de la spécification découle du large éventail de moyens permettant d’établir cette connexion entre les deux entités. La question principale est la complexité de votre déploiement".

Il y a là des fonctions de sécurité entièrement à la charge des serveurs de ressources protégées. Un serveur d’autorisation fournit un jeton d’accès et des informations d’authentification, la sécurité obtenue dépendra en définitive de ce que le serveur de ressources protégées en fait, ou n’en fait pas !

Faciliter en toute sécurité la navigation et l’échange de données au sein d’une application multiple

OAuth a de nombreuses applications, cependant les cas suivants en illustrent bien les possibilités :

Authentification unique pour un groupe d’applications

Lorsque l’application comporte différents logiciels sur différents sites, ou utilise plusieurs serveurs (c’est le cas "dans le Cloud"), ou encore si elle est fondée sur une architecture REST (sans état ni session), il n’est pas praticable de demander à un même internaute plusieurs authentifications successives. Voyez comment OAuthSD apporte la solution sans nécessiter de modification des applications : SLI, SLO et SRA sont dans un bateau : OAuthSD.

Un cas de figure très simple est celui d’un CMS ( Wordpress, SPIP ...) auquel on souhaite adjoindre une application de forum étrangère au CMS ( SPIP, PhpBB, WP ... ). Le serveur d’authentification permet de ne demander qu’une seule fois à l’internaute de s’identifier.

Cela devient très puissant dans le cas d’une application de vente couplée à un CMS et liée avec plusieurs blogs et forums : la navigation d’un utilisateur à travers le groupe d’applications ne nécessitera qu’une seule procédure d’authentification. On peut également envisager d’autoriser l’accès de cet utilisateur aux pages publiques le concernant d’un CRM (ou plus généralement d’un ERP) lié au site de vente.

Sécurité des communication entre applications

Un cas de figure classique est celui d’une application principale faisant appel à différentes ressources qui lui sont extérieures. Une fois l’internaute authentifié sur l’application principale, les serveurs de ressources doivent être certains de l’origine des requêtes qui leur sont faites.
A minima, le serveur d’authentification permet de ne pas dévoiler le login et mot de passe de l’utilisateur aux applications tierces. Mais l’avantage déterminant d’OpenID Connect est de fournir un jeton d’identité dans lequel l’identité de l’application cliente, l’identification de l’utilisateur et les autorisation d’accès sont liées par une signature cryptographique qui pourra être validée par le serveur de resource destinataire.

Session inter applications

En plus des services définis par le stantard OAuth, OAUTH Server by DnC offre en exclusivité le moyen d’échanger très simplement des informations de façon sécurisée entre applications web : c’est le service de CloudSession.

Pestataires Web, protégez vos intérêts et protégez vos clients

Étant propriétaire de site web ou développeur, vous pouvez résoudre la question de l’authentification unique en la délégant à G..gle, F...book etc.. Ce faisant, vous offrez à ces prestataires une magnifique occasion d’analyse comportementale de vos clients et de ciblage publicitaire. Mieux encore : vous exigez de vos clients qu’ils enregistrent sur ces services des renseignements confidentiels, dont la plupart, au delà du pseudonyme et du mot de passe, sont parfaitement inutiles dans un simple but d’authentification !

De plus, pensez-vous que cette façon de faire est compatible avec la RGPP ?

Protégez vos intérêts commerciaux

Vous pouvez penser que, de toutes les façons, la plupart de vos clients ont un compte G..gle ou F...book etc.. C’est vrai, mais tout n’est pas perdu : vous pouvez au moins faire en sorte que ces prestataires publicitaires ne pistent pas la navigation de vos clients dans vos applications ( tracking ), ce qui ne manquerait pas de provoquer l’affichage de publicité de vos concurrents dans la suite de leur navigation sur le web.

Créez la confiance

En utilisant notre plateforme d’authentification, vous montrez à vos clients que vous vous attachez au respect de leur vie privée en protégeant leurs données personnelles.

OAuth 2.0 : comment cela fonctionne ?

  publie le par DnC

Ce résumé permet d’acquérir une idée générale. Les développeurs se rapporteront à la rubrique Développeurs.

La caractéristique principale d’OAuth 2.0 tient au faut fait que l’utilisateur n’a plus besoin de fournir ses informations d’identification à chaque application à laquelle il accède car la procédure de connexion (la fourniture du login et du mot de passe) se passe sur le serveur d’authentification. On parle d’authentification déléguée. OpenID Connect hérite de ce principe.

Le schéma de processus ci-dessous explicite le concept :

fig 1 : L’application ne voit que des jetons, pas les identifiants personnels.

 

L’application ne voit jamais les identifiants de connexion (login et mot de passe), ni d’autres informations personnelles qui pourraient être demandées pendant la procédure d’autorisation, celles ci-circulant exclusivement, et de façon cryptée, entre le navigateur de l’utilisateur et le serveur OAuth.

Ensuite, la communication entre le serveur OAuth et les serveurs d’applications tierces transportent des jetons (Token), et non les identifiants de connexion [1].

Sans entrer dans les détails, notons la magie qui se cache derrière "Call application with access token".
Comment le jeton est-il validé ? Il y a là un sujet généralement laissé dans l’ombre et que nous allons amplement développer, jusqu’à préconiser l’emploi exclusif d’OpenID Connect.

La délégation d’authentification présente de nombreux avantages :
- protection des identifiants de connexion (comme illustré ci-dessus),
- enregistrement unique : un seul enregistrement des login et mot de passe sur le serveur d’authentification pour se connecter à toutes les applications compatibles,
- connexion unique : une seule fourniture de login et de mot de passe pour une navigation entre plusieurs applications compatibles,
- protection de l’accès aux ressources externes tels que les web-services.

Ce dernier point mérite un développement. Alors que le point de vue sur OAuth 2.0 et OpenID Connect est le plus souvent réduit à un moyen de connexion unique (Single Sign On ou SSO), la transmission de jetons aux ressources protégées offre à celles-ci le moyen de vérifier l’authenticité de la requête qui leur est faite, en identifiant de façon certaine l’application qui est à l’origine de la demande ainsi que l’utilisateur final. OAuthSD et OpenID Connect apparaissent alors comme un système de sécurisation global des accès à un ensemble de ressources répartie sur les réseaux.

Notes

[1Soulignons cette communication de serveur à serveur, ou "background connection" : dans le cas d’OpenID Connect, seul le flux "Authorization code" ne passe jamais les jetons par le navigateur du client final, raison pour laquelle nous mettrons au deuxième plan les autres flux dans le cadre d’OAuthSD (bien que ces flux soient implémentés par OAuthSD).

Réaliser l’identification (Authentification)

  publie le par DnC

Rappelons le : OAuth n’est pas un protocole d’authentification. Cela provient du fait qu’une application cliente qui reçoit un code d’autorisation (Authorization Code) de la part de OAuth n’a aucune connaissance de l’identité de l’utilisateur qui a émis l’autorisation, et ne peut donc savoir si il est le propriétaire de données protégées. Ces informations ne sont pas véhiculées par le code d’autorisation. C’est la même chose pour un serveur de ressource qui reçoit un jeton d’accès (Access Token).

Par définition, l’authentification suppose d’accéder aux données d’identification. De plus, seul le serveur de ressources sait à qui appartiennent les ressources (typiquement un jeu de données associées à une personne). L’authentification ne peut donc être réalisée qu’avec une étape supplémentaire mettant en jeu le serveur de ressources.

Notons que OAuth Server by DnC prend quelques libertés en étendant la norme avec un point d’extrémité "resource" qui permet de valider les jetons d’accès et d’obtenir l’identificateur de l’utilisateur final ainsi que des données sur son profil. Voir : Validation du jeton d’accès par interrogation du serveur d’autorisation (Introspection).

Différentes solutions permettent de construire une authentification avec OAuth. Elles consistent à accéder à une API ( un web service ) associée au serveur OAuth pour obtenir les informations sur l’utilisateur.

Malheureusement, il y a autant d’API que de fournisseur d’authentification (Providers) : Google, Facebook, Twitter, LinkedIn etc.). Ces fournisseurs désignent leur protocole d’authentification sous le nom de OAuth, alors qu’il s’agit de protocoles particuliers construits au-dessus ou à côté de OAuth. Cette confusion, et la distinction qu’il convient de faire, sont expliquées en détail dans cet article : Généralités sur l’authentification, introduction d’OpenID Connect.

Face à ce problème, il existe (au moins) deux solutions :
- utiliser une bibliothèque permettant d’abstraire le processus d’accès aux données, pré-configurée pour les fournisseurs les plus connus ;
- utiliser le protocole OpenID Connect qui, largement utilisé, peut faire figure de standard.

Cette deuxième solution nous parait préférable, dans la mesure où la plupart des fournisseurs d’authentification (et en particulier Google) proposent maintenant OPenID Connect.

Utiliser OpenID Connect

Nous décrivons dans cet article comment mettre en oeuvre OpenID Connect dans une application cliente :
- OpenID Connect : Lier une application cliente au serveur OAuthSD

Les articles suivants décrivent plus en détail l’implémentation de OpenID Connect par OAuth Server byDnC :
- OpenID Connect
- Réponse UserInfo

Utiliser une couche d’abstraction

Dans cet article, nous décrivons comment accéder à OAuthSD avec Lusitanian/PHPoAuthLib.
Finlement, nous nous ramenons au protocole OpenID Connect.

OAuth 2.0 ou OpenID Connect ?

  (publie initialement le jeudi 20 septembre 2018) par DnC

Le serveur OAuthSD offre deux protocoles : OAuth 2.0 et OpenID Connect [1]. 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 sécurité grâce à la signature du jeton.

Le jeton d’accès fourni par OAuth 2.0 est un simple hash de valeur aléatoire, non signé, donc obscur pour la ressource protégée qui le reçoit. La spécification d’OAuth 2.0 ne définit pas comment le jeton passé à un serveur de ressource doit être validé par celui-ci. Ceci est laissé à l’initiative du développeur, avec un certain nombre de défauts :

- puisqu’il n’y a pas de méthode standard, les implémentations d’OAuth sont nécessairement toutes propriétaires.

- l’absence de spécification ouvre la porte à des développements insuffisamment sécurisés.
Notamment, OAuth 2.0 ne définit pas comment un serveur de ressources protégées doit vérifier la validité du jeton d’accès ni comment interpréter l’étendue des autorisations (scopes). Dans le cas de ce serveur OAuthSD, nous avons choisi d’ajouter aux points d’entrée définis par la "norme" un point d’entrée d’introspection, auquel une ressource doit s’adresser pour valider le jeton qui lu a été passé.

- enfin, les flux OAuth 2.0, retournant des jetons non signés (alors que OAuth 1 assurait la signature !), ne sont sécurisés que si l’on peut "faire confiance" aux applications clientes (par exemple, l’URL de retour est "codée en dur" dans l’application). Autant dire qu’ils ne sont sécurisés que dans un espace propriétaire (corporate realm). Pour être utilisés dans un espace ouvert, il manque une signature pour authentifier, comme le démontre brillament un des concepteurs d’OAuth 2.0, Eran Hammer : OAuth 2.0 (sans signature) est mauvais pour le Web :
"OAuth 2.0 supprime les signatures et la cryptographie en faveur des jetons portés, semblables au cookies. En tant qu’éditeur d’OAuth 2.0, je suis associé au protocole OAuth 2.0 plus que la plupart des autres, et l’hypothèse est que je suis d’accord avec les décisions et les orientations prises par le protocole. Bien que le fait d’être éditeur donne un certain degré de contrôle temporaire sur la spécification, les décisions sont finalement prises par le groupe dans son ensemble (comme il se doit).
Et dans son ensemble, la communauté OAuth a commis une grave erreur (ndlr : en supprimant la signature des jetons) quant à l’orientation future du protocole. Une erreur qui fera d’OAuth 2.0 un agent de changement beaucoup moins important [2] sur le Web."

Il faut donc passer à OpenID Connect !

OpenID Connect [3] complète les fonctionnalités d’OAuth 2.0 pour apporter, avec le jeton JWT signé [4], des informations sûres sur l’application cliente, la portée de l’autorisation (scope) et, le cas échéant, sur l’utilisateur connecté à l’application cliente.

Que reste-t-il d’OAuth 2.0 ?

Dans un "espace de confiance" (dont les communications sont au minimum protégé par TLS), certains pourront considérer que l’identification de l’utilisateur final n’est pas nécessaire, ni la vérification de l’application cliente. Ceux-là utiliseront les flux d’OAuth 2 pour leur simplicité, et en particulier le flux Autorisation de Serveur à serveur (Client Credentials Grant) pour assurer l’accès des applications à une API protégée.

Suggestion de parcours à propos d’OpenID Connect

Ce site est complexe, à l’image du sujet [5]. Voici donc une suggestion de parcours :
- Généralités sur l’authentification, introduction d’OpenID Connect
- OpenID Connect : Autorisation via un code (Authorization Code Flow)
- OpenID Connect : UserInfo
- JSON Web Token (JWT)
- Un jeton d’identification peut être utilisé pour ...
- OpenID Connect : Exemples complets du flux d’Autorisation via un code puis requête UserInfo
- Synthèse des flux d’autorisation (Grant Type) d’OpenID Connect

Notes

[1Noter que OpenID Connect est un standard distinct d’OpenID.

[2Un euphémisme pour dire "un changement catastrophique pour la sécurité du Web".

[3Une petite subtilité : Google met en oeuvre OpenID Connect sous la dénomination OAuth 2.0.

[4Appelé "jeton d’identité (ID Token)".

[5Note de l’auteur : Je reconnais que ce site est mal organisé, car les rubriques et les articles ont été composés au fur et à mesure de mon apprentissage. J’ai commencé ce serveur en 2016, époque à laquelle tout me semblait confus sur le Web, voire erroné. Avec le temps, la connaissance du sujet s’affine, pour preuve l’article lumineux de Matthieu Mabyre : "Authentification et habilitations avec OpenID Connect, OAuth 2 et JWT". Cependant le terme "jeton auto-porté" reste non défini, tout comme la procédure de vérification du jeton : cet article est donc une excellente introduction, en termes précis et cohérents, mais ne va pas jusqu’au bout de la technique.

Le serveur OAuth que DnC met à votre disposition

  publie le par DnC

Avertissement : Ce serveur est un démonstrateur et un outil de développement, il peut être indisponible et les données enregistrées effacées à tout moment. Les développeurs intéressés par une version de production de OAuthSD peuvent s’adresser à DnC

Dans le cadre des applications que DnC développe pour ses clients, nous avons pour ambition d’offrir un serveur OAuth efficace en proposant un interface utilisateur pratique complété par une documentation accessible.

L’engagement de DnC à ne pas divulguer les données est un moyen pour les entreprises de se protéger de la concurrence. C’est aussi un avantage concurrentiel que les entreprises peuvent faire valoir auprès de leur clients et utilisateurs finaux.

Tout en restant conforme au standard, OAauth Server by DnC apporte de nombreuses améliorations tout en respectant les spécifications.

OAuth Server by DnC est conforme à La norme OAuth 2.0 (RFC 6749) et s’appuie sur la librairie développée par Brent Shaffer (voir : http://bshaffer.github.io/oauth2-se...).

PNG - 33.8 ko
Architecture d’OAuth Server by DnC

DnC a encapsulé cette bibliothèque dans une application serveur, en apportant les développements suivants :

- Le protocole OpenID est implémenté avec des extensions exclusives :

  • Avec les flux OpenID Connect, le contrôleur Authorize est développé pour assurer la SSO et 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). Voir : 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.
  • Dans un domaine du réseau local contrôlé par Kerberos, OAuthSD utilise l’authentification Kerberos de sorte que l’utilisateur ayant initié une session locale (avec Active Directory s’agissant du système Windows) n’a pas à s’identifier à nouveau pour accéder aux application clientes du serveur OAuthSD.
  • OAuth Server by DnC permet d’ajouter aux données utilisateur (claims), prévues par la norme OpenID Connect, des informations complémentaires correspondant aux processus métiers, pour les applications d’e-commerce par exemple.

- OAuthSD complète le noyau OAuth 2.0 :

  • en permettant aux serveurs de données protégées de valider les jetons d’accès (introspection),
  • en fournissant l’identification de l’utilisateur final à l’origine de l’autorisation pour assurer la fonction d’authentification.

- OAuthSD offre un interface d’exploitation et une documentation

  • Un interface utilisateur convivial (ce site web) permet de configurer le serveur et offre une documentation détaillée pour sa mise en œuvre ainsi que pour l’adaptation de vos applications.
  • Un rôle d’Administrateur d’applications s’ajoute aux rôles définis par la norme : ceux-ci créent et gèrent sur ce serveur les applications clientes dont ils délèguent l’authentification, et dont ils sont donc propriétaires. Ils peuvent également documenter sur le site web du serveur les aspects particuliers du processus d’authentification de leurs applications (ils sont Auteurs au sens de SPIP).
  • Le modèle d’application est étendu pour permettre de gagner la confiance de l’utilisateur en l’informant avec précision sur l’identité de l’administrateur de l’application, le fonctionnement de l’application et l’utilisation des données personnelles.
  • Alors que le paramètre State est facultatif dans la définition du protocole OAuth, ce paramètre est obligatoire pour OAuth Server by DnC afin de renforcer la sécurité.
  • Lors de la procédure d’autorisation, le mot de passe de l’utilisateur final n’est pas entré au clavier, mais à la souris dans une grille aléatoire (GhostKeys). Ainsi, les mots de passe n’ont pas d’existence physique, sont cryptés dès la saisie, et ne peuvent donc être interceptés par un pourriciel.

Avec OAuth Server by DnC, les mot de passe ne peuvent être interceptés au moment de leur saisie, ne circulent pas sur Internet, ne sont enregistrés nulle part !

- Identity renforce l’authentification de l’utilisateur final :
Identity by DnC utilise OAuth et OAuthSD pour étendre les capacités d’identification de l’utilisateur final, qu’il soit un humain ou une machine. Comme OpenID, Identity offre une couche complète se substituant à OAuth.

 

Pour entrer rapidement dans le sujet, voyez :
- SLI, SLO et SRA sont dans un bateau : OAuthSD,
- Exemples complets du flux d’Autorisation,
- OpenID Connect : Lier une application cliente au serveur OAuthSD.

Définitions

  publie le par DnC

Administrateur d’applications

Un développeur ou un propriétaire de sites Web, utilisateur privilégié, notamment propriétaire d’une ou plusieurs applications clientes qu’il a inscrites sur ce serveur en vue de déléguer les authentifications.
Nota : cette notion est propre au serveur OAuthSD de DnC.

Autorisation

Requête de la part d’une application cliente vers :
- soit une personne (utilisateur final) à qui il est demandé d’autoriser ou de refuser l’accès à une ressource.
- soit une machine dans le cas de l’autorisation serveur à serveur.

Client, Application cliente

Un Client est une application inscrite sur ce serveur par un administrateur. Plutôt que de réaliser elle-même l’authentification des utilisateurs, l’application cliente délègue cette action au serveur OAuth. Cela permet également d’autoriser l’accès aux ressources protégées appelées par cette application.
Dans le contexte OpenID, un client est dénommé Relying Party (RP).

Diagramme de Flux (Flow Chart), Flux d’Autorisation (Grant Flow)

Représentation graphique de la séquence des échanges entre les Rôles. Il existe un Diagramme de Flux distinct pour chacun des 4 types d’Autorisation ou Flux.

Type d’Autorisation (Grant Type)

OAuthSD prend en charge plusieurs types d’autorisation, qui sont des méthodes permettant d’obtenir des jetons d’accès (valeurs de chaîne représentant les autorisations accordées). Différents types d’autorisation autorisent différents types d’accès et, en fonction des besoins de votre application et la nature des ressources, certains types d’autorisation sont plus appropriés que d’autres. Mais attention : tous ne sont pas parfaitement sécurisés !

Jeton (Token)

Le jeton est une chaine de caractères générée par le serveur d’autorisation. Il est émis en réponse à une demande de l’application cliente.

Dans le cadre de OAuth 2.0, on distingue 2 types de jetons :

- Le jeton d’accès (Access Token) : Permet au serveur d’une ressource protégée d’autoriser une application cliente à y accéder. Ce jeton est envoyé par l’application cliente en tant que paramètre ou en tant que header dans la requête vers le serveur de ressources. Il a une durée de vie limitée qui est définie par le serveur d’autorisation.

- Le jeton de renouvellement (Refresh Token ) : Utilisé pour demander de prolonger l’accès à une ressource ; envoyé sur demande d’une application qui détient déjà un jeton d’accès valide.

Le protocole OpenID Connect introduit le jeton d’identité (ID Token). De type JSON Web Token, ce jeton transporte des données relatives à l’authentification : application cliente, identité et profil de l’utilisateur final, étendue de l’autorisation. Étant crypté et signé, il offre un moyen sûr de contrôler l’accès aux ressources protégées.

Rôles

Les protocoles d’authentification de OAuth définissent les échanges entre 4 rôles :

- Le détenteur des données (Ressource Owner) : une ressource matérielle, ou une personne (Utilisateur Final), qui autorise l’accès à une ressource protégée.

- Le serveur de ressources (Ressource Server, RS) : serveur qui héberge les ressources protégées, et répond aux demandes d’accès aux ressources protégées selon le jeton d’accès (Access Token). Dans le contexte OpenID,

- Le Client ou l’Application Cliente (Client, Client Application) : application demandant des ressources protégées au nom du propriétaire de celles-ci et avec son autorisation. Le client est inscrit sur le serveur par un administrateur d’application qui en configure les caractéristiques.
Dans le contexte OpenID, un client est dénommé Relying Party (RP).

- Le Serveur d’autorisation (Authorization Server, AS) : serveur qui délivre des jetons d’accès (Access Token) au client après que le propriétaire de la ressource a été formellement authentifié et qu’il a obtenu une autorisation de sa part.

Dans le contexte OpenID, le serveur d’autorisation délivre un jeton d’identification (ID token) en réponse à une demande d’authentification, ce qui justifie la dénomination OpenID Provider (OP ou IdP).

Etendue (ou portée) de l’autorisation (Scope)

Les Scopes définissent l’étendue des droits ( les actions permises sur les données de la ressource ) attachés au token d’accès. La liste des Scopes disponibles est définie par l’Auteur pour chacune de ses applications clientes du côté du serveur d’autorisation. La signification d’un scope dépend exclusivement de ce que le serveur de ressources protégées en fait (ou n’en fait pas), le serveur d’autorisation étant transparent à cet égard.

URI de redirection (Redirect URI)

Une URI absolue de l’application cliente à laquelle le serveur redirige l’user-agent de l’utilisateur final à la suite du processus d’authentification, et à laquelle il adresse le résultat.

Utilisateur, utilisateur final (End User)

Internaute répondant aux requêtes d’authentification. Ses identifiants sont inscrits sur le serveur d’authentification (et non du côté des applications clientes).

 

Mentions légales

  publie le par DnC

Avertissement

Avertissement : Ce site un démonstrateur et un outil de développement, il peut être indisponible et les données enregistrées effacées à tout moment.

Cette application est un prototype en développement. Elle est destinée à permettre à DnC, à ses clients et aux développeurs de tester OAuth dans leurs applications clientes et leurs serveurs de ressources protégées. Toute utilisation se fait aux risques et périls de l’utilisateur.

La documentation est également en devenir constant et ne saurait remplacer les documents auxquels elle fait référence.
DnC n’offre aucune garantie et nie toute responsabilité pour quelque dommage que ce soit résultant de l’application ou de la documentation.

Droits

L’ensemble de ce site relève de la législation française et internationale sur le droit d’auteur et la propriété intellectuelle. Tous les droits de reproduction sont réservés, y compris pour les documents téléchargeables et les représentations iconographiques et photographiques.

L’éditeur revendique les droits d’auteur sur la totalité des textes de ce site, hormis les traductions qui cherchent à coller au plus près du texte original indiqué en référence. En revanche, l’éditeur revendique les droits liés à la traduction.

Informations sur l’éditeur

- Editeur du site : DnC SARL Degoy net Consultants - 76, avenue du Général Leclerc - 92340 - Bourg la Reine - tél : 07 86 82 24 90

- Hébergement sur serveur privé loué à OVH SAS, 2 rue Kellermann - 59100 Roubaix - France mis en oeuvre par DnC SARL.

- Responsable de la rédaction : L’éditeur du site.

Informatique et libertés

Dans l’état actuel du développement, ce site n’enregistre aucune donnée personnelle de façon permanente (les données entrées par les auteurs et les utilisateurs sont effacées régulièrement et sont supposées fictives) et ne nécessite pas de déclaration à la CNIL.

Cookie  : Nous souhaitons implanter un cookie de durée de vie limitée dans votre ordinateur. Ce cookie ne nous permet pas de vous identifier ; il n’enregistre aucune information personnelle ou relative à la navigation de votre ordinateur sur notre site, mais simplement un code aléatoire permettant de gérer la continuité de la navigation dans le site (session). Notez que ce type de cookie ne requiert pas votre consentement préalable, car ce n’est pas un "cookie de tracking". Nous vous informons qu’il vous appartient de vous opposer à l’enregistrement de cookies en configurant votre navigateur. Cependant, cela provoquera des dysfonctionnements.