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 + OpenID 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).

OAuth ou OpenID Connect ?

, par DnC

Le serveur OAuthSD offre deux protocoles : OAuth 2.0 et OpenID Connect [1]. Lequel utiliser ? Le deuxième, évidemment !

OAuth 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. Construit sur OAuth 2.0, OpenID Connect a pour but d’apporter les fonctions nécessaires à l’identification de l’utilisateur final par les applications clientes.

Par ailleurs, 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.
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é.

Il est vrai que OAuth offre un flux "JWT Bearer Authorization Grant" ou "Client Authentication" qui produit un jeton JWT transportant des informations sur l’application cliente. En revanche, pour obtenir plus d’information d’identité, notamment sur l’utilisateur connecté à l’application, il doit être fait appel à un web service complémentaire qui donne lieu à des implémentations variées.

Si on envisage d’utiliser JWT, alors autant passer à OpenID Connect !

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

OAuth 2 reste utile, voire indispensable

Mais si JWT n’est pas indispensable (on ne s’intéresse qu’à l’autorisation d’accès, pas à l’identité de l’utilisateur final), les flux d’OAuth 2 pourront être utilisés pour leur simplicité.

Il convient de faire une remarque importante : le jeton d’accès suffit au serveur pour identifier l’application cliente et l’utilisateur connecté. En effet, même si le jeton d’accès est opaque, il est enregistré dans la base de données du serveur OAuthSD (table access_token) avec l’ID du client (champ client_id) et l’ID de l’utilisateur connecté (champ user_id), sans oublier la date limite de validité (champ expires). on se réfère à ces données pour établir le fait que l’utilisateur est connecté ou non.
Donc, le jeton d’accès est indispensable pour toutes les applications le retournant au serveur pour vérification de la connexion de l’utilisateur (par exemple pour utiliser la session de l’utilisateur sur le serveur d’authentification, pour gérer les sessions d’une application à page unique (SPA) etc.).

Suggestion de parcours à propos d’OpenID Connect

Ce site est complexe, à l’image du sujet. [3] 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

Notes

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

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

[3Note 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 JWE : cet article est donc une excellente introduction, en termes précis et cohérents, sans aller au bout de la technique.

Pourquoi un serveur d’authentification ?

, 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 connexion 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 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, OAuth 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.

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 des serveurs de ressources protégées (par exemple un web service), le seul fait d’utiliser OAuth n’améliore en rien un serveur de ressources protégées qui présenterait des défauts de sécurité. En somme, côté serveur de données, il ne faut pas voir OAuth comme une barrière de sécurité (une encapsulation, un proxy, un firewall etc.).

OAuth 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 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. Il s’agit à la fois d’un profil et d’une extension d’OAuth. 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.

Ce que fait OAuth Server by DnC et ce qu’il reste à faire

OAuth Server by DnC étend OAuth :
- 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.
En particulier, OAuth Server by DnC répond également à la norme OPenID Connect.
La compatibilité avec OAuth 2.0 reste parfaitement assurée.

Cependant, OAuth 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 !

OAuth Server by DnC offre une base solide que les développeurs devront compléter dans deux directions de travail :
- Lier une application cliente au serveur OAuthSD,
- Adapter les serveurs de données protégées à la validation du jeton d’accès et à l’authentification de l’utilisateur final.

Le premier axe est très standard. Toute application cliente offrant l’authentification par OAuth ou OpenID Connect pourra très probablement être inscrite sur OAuthSD sans modification.
En revanche, ce qui doit être fait du côté des serveurs de données dépend étroitement de l’application, de la nature des données et des droits que l’on souhaite offrir aux différents profils d’utilisateurs.

Notre ambition est d’offrir une plateforme et une documentation facilitant le travail des développeurs.

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

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 ( PhpBB ... ). 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 le protocole OAuth sera pleinement utilisé si on offre à l’internaute le moyen de contrôler les permissions d’accès à ses propres données qu’il accorde à ces applications tierces.

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 : comment cela fonctionne ?

, par DnC

Ce résumé permet d’acquérir une idée générale, avec des liens vers des textes auxquels se réfèreront les lecteurs désireux d’approfondir la question. Les développeurs se rapporteront à la rubrique Développeurs.

L’intérêt majeur d’OAuth vient du fait que l’utilisateur n’a plus besoin de fournir ses informations d’identification à une application car la procédure de connexion (la fourniture du login et du mot de passe) se passe sur le serveur OAuth.

Le schéma de processus ci-dessous explicite le concept : 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].

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

 

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.

Articles recommandés :

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 ne décrirons ni ne mettrons en œuvre les autres flux dans le cadre d’OAuthSD (bien que ces flux soient implémentés par OAuthSD).

Le serveur OAuth que DnC met à votre disposition

, 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 visant à mieux informer l’utilisateur final pour lui permettre d’approuver les demandes d’autorisations en toute confiance.

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 :

- OAuthSD complète le noyau OAuth 2.0 :

  • 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.
  • Les portées de l’autorisation (Scopes) sont explicitées, afin que l’utilisateur final puisse les approuver en toute connaissance de cause.
  • 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 !

- Le protocole OpenID est implémenté :
Le protocole OpenID apporte des interfaces standardisés pour réaliser l’authentification du client final.
OpenID Connect est implémenté par la bibliothèque de Brent Schaffer. OAuth Server by DnC étend cette bibliothèque en ajoutant aux données utilisateur (claims) prévues par la norme OpenID Connect, des informations complémentaires utiles pour les applications d’e-commerce.
OpenID Connect est construit au-dessus de la couche OAuth pour offrir des flux d’autorisation distincts.

- 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 :
- Exemples complets du flux d’Autorisation.
- OpenID Connect : Lier une application cliente au serveur OAuthSD.

Définitions

, 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, y compris l’identité et le profil de l’utilisateur final. É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 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

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