Accueil > OpenID Connect OAuth Server par DnC > Développer > OpenID Connect > Découvrir

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 ?

  publié le par DnC

Les réseaux sociaux ont vulgarisé l’authentification comme moyen pour l’utilisateur d’autoriser l’accès à ses données personnelles. D’autres n’ont vu dans OAuth que l’identification unique (Single Sign-On, SSO).

Sans négliger ces objectifs, le contrôle de l’accès des utilisateurs aux applications, et des applications aux ressources protégées, constituent l’angle d’attaque de ce site.

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 dans une application composée de plusieurs composants répartis sur l’Internet et l’échange de données entre ces composants sont 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.

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" : parce-que OAuth 2.0 fournit 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 et celle de l’application. 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.

"un propriétaire de ressource" : Il est facile de se représenter ce qu’est un propriétaire de ressource dans le cas le plus courant : un utilisateur se connecte à une application qui a besoin d’accéder à des données sensibles le concernant (son identité, sa position etc.).

"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 [1].

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.

Prestataires 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 le Règlement Général de Protection des Données (RGPD) ?

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 la navigation de vos clients 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.

Notes

[1Cet article est le premier de ce site. Après avoir utilisé pendant quelques temps des jetons signés pour authentifier l’accès à des web-services, j’ai découvert fin 2015 - début 2016 grâce à Eran Hammer l’inquiétante évolution d’OAuth 2.0 et, fort heureusement, la réponse d’OpenID Connect à la question de l’authentification.

Il m’est apparu que, si l’utilisateur final était alors bien identifié, la transmission du Jeton d’Identité signé à des ressources protégées posait la question de la vérification de l’application et que la question aussi bien que la réponse étaient mal mises en évidence. Le contrôle de l’accès des utilisateurs et des applications aux ressources protégées est le fil rouge de ce site.

OAuth 2.0 : comment cela fonctionne ?

  publié le par DnC

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

La caractéristique principale d’OAuth 2.0 tient au faut fait que l’utilisateur n’a plus besoin de s’inscrire sur chaque application à laquelle il veut accéder car la procédure de connexion (la fourniture du login et du mot de passe) se passe sur le serveur d’authentification. Il est donc nécessaire de ne s’inscire qu’une seule fois. On parle d’inscription unique (Single Sign On, SSO) . 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).

Identification de l’utilisateur final

  publié le par DnC

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 secondaires. Les constantes de configuration IDENTITY_PROVIDER et TFA_PROVIDER permettent de définir quel seront les systèmes utilisés.

OAuthSD offre les systèmes d’identification suivants :

- Identification primaire (constante IDENTITY_PROVIDER) :

  • ’password’ : identification classique par login et mot de passe,
  • ’ghostkeys’ : identification par login et mot de passe entré dans une grille aléatoire.

- Identification secondaire (constante TFA_PROVIDER) :

  • ’checkbysms’ : la classique vérification par SMS,
  • ’gangsta’ : identification de type TOTP (Time-based One-time Password) avec Google Authenticator (DnC développe votre propre TOTP pour plus de sécurité).
    (plus à venir ...)

En savoir plus :
- Validation en 2 étapes (Two Factor Authentication, 2FA) .

Délégation de l’identification à un Identity Provider

Une facilité consiste à utiliser les services d’identité de Google, Facebook, Twitter etc. Cela procure certainement un grand confort pour l’utilisateur et illustre parfaitement le principe du SSO.
Cependant ce n’est pas le bon moyen d’assurer la confidentialité que l’on souhaite dans une organisation mettant en œuvre des informations protégées qui lui appartiennent. Permettre à un utilisateur de se connecter simultanément à un réseau social et à des applications métiers de l’organisation au moyen du même cookie de suivi est certainement ce que l’on peut imaginer de pire en matière de protection des données.

OAuthSD permet d’intégrer des systèmes d’identification tiers, qu’il s’agisse de standard tels que LADP et Active Directory (Kerberos) ou spécifiques à une organisation (ID card, identification biométrique ...). Un tel système peut aussi bien se substituer à l’identification primaire que secondaire.

En savoir plus :
- Identification SSO des utilisateurs identifiés avec Kerberos.

OAuth 2.0 ou OpenID Connect ?

  (publié 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, le protocole 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.

Une tendance est donc de considérer OAuth 2.0 comme une infrastructure (en oubliant ses protocoles) et OpenID Connect comme un protocole construit sur OAuth 2.0.

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 [2]. 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 brillamment 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 aux 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 [3] sur le Web."

Il faut donc passer à OpenID Connect !

OpenID Connect [4] complète les fonctionnalités d’OAuth 2.0 pour apporter, avec le jeton JWT signé [5], 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.

Cependant, la signature du jeton ne suffit pas. Il ne faut pas écarter la possibilité d’un vol de jeton qui sera présenté par une application étrangère. OAuthSD prend en compte ce cas de figure (voir : Vérification de l’origine de la requête reçue par un serveur de ressource). Cette approche stricte de la sécurité conduit à la conclusion que seul le flux Authorization Code peut être considéré comme sûr.

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.

Quoi qu’il en soit, OAuth 2.0 reste une infrastructure sur laquelle sont construits de nouveaux protocoles comme OpenID connect. Une tendance est donc de considérer OAuth 2.0 comme une infrastructure (en oubliant ses protocoles) et OpenID Connect comme un protocole construit sur OAuth 2.0.

Suggestion de parcours à propos d’OpenID Connect

Ce site est complexe, à l’image du sujet [6]. 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
- OpenID Connect : Synthèse des flux d’autorisation (Grant Type)

Notes

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

[2C’est même bien pire que cela : la nécessité de le vérifier n’est pas mentionnée. Il faut attendre la spécification d’OpenID Connect pour apprendre que le jeton d’identité doit être systématiquement vérifié. On peut se demander si un certain nombre de codeurs n’ont pas utilisé OAuth 2.0 en accordant une propriété magique au jeton d’accès. Peut-être pensaient-ils que le protocole s’occupait de tout ? Des témoignages d’informaticiens expérimentés, selon lesquels des codeurs utilisaient des bibliothèques sans même comprendre la logique des échanges entre un serveur et un user-agent, ou sans même savoir qu’il y avait des serveurs derrière l’application qu’ils développaient côté client, donnent à penser que des applications ont pu fonctionner - et fonctionnent toujours - avec des failles de sécurité béantes.

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

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

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

[6Note 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.

OpenID Connect : Synthèse des flux d’autorisation (Grant Type)

  (publié initialement le mardi 8 janvier 2019) par DnC

Les tableaux de cet article synthétisent les flux offerts par OpenID Connect et la couche sous-jacente OAuth 2.0. Il permet de naviguer vers les têtes de chapitres correspondantes de la documentation.

La plupart des fonctionnalités d’OAuth 2.0 sont intégrées au protocole OpenID Connect. Les fonctionnalités d’OAuth 2.0 et de OpenID Connect peuvent donc être atteintes par les Points d’extrémité d’OpenID Connect [1].

Type de flux selon les paramètres de l’appel à Authorize

1. Requêtes adressées au point d’extrémité authorize. Les différentes valeurs du paramètre response_type (obligatoire) et du scope openid (facultatif) déterminent les flux d’autorisation (Grant Type) suivants :

Grant Type response_type openid Rem.
OAuth 2.0 Authorization Code code N RFC 6749
OIDC Authorization Code code Y
OAuth 2.0 Implicit token X [2] RFC 6749
OIDC Implicit id_token, id_token token Y [3] OpenID Connect Implicit Client. ’nonce’ est requis.
OIDC Hybrid code id_token Y ’c_hash’ est requis
Hybrid code token X Invalid [4]
Hybrid code id_token token Y Invalid [4]

Références :
- The OAuth 2.0 Authorization Framework.
- OpenID Connect Core 1.0 incorporating errata set 1 : Authentication using the Hybrid Flow.


Notes :
- A propos des response type "id_token" et "id_token token" :
ces types de réponse correspondent à des flux implicites retournant directement les jetons. Le paramètre "nonce" doit être présent dans la requête.

- A propos des response type "code token" et "code token-id token" :
ces types de réponse correspondent à des flux hybrides retournant directement le ou les jetons. OAuthSD est fondé sur la librairie OAuth 2.0 Server PHP développée par Brent Shaffer. Dans le cadre d’OpenID Connect, celle-ci n’accepte que la demande de flux hybride "code id_token".


2. Requêtes adressées directement au point d’extrémité token. Ces flux ne sont définis que par OAuth 2.0 et ne retournent pas de jeton d’identité, que le scope openid soit indiqué ou non.

Grant Type grant_type Access Token Refresh Token Rem.
Client Credentials client_credentials Y Y  [5]
User Credentials [6] password Y N
JWT Bearer - Y N  [7]

References :
- RFC 6749 Client Credentials Grant,
- Spécification draft-ietf-oauth-jwt-bearer-07 section 1

Synthèse des fonctionnalités offertes par les différents flux OpenID Connect

Voir : https://openid.net/specs/openid-connect-core-1_0.html#Authentication

Propriété Flux de codes d’autorisation Flux implicite Flux hybride
Tous les jetons renvoyés depuis le contrôleur Authorization non oui non
Tous les jetons renvoyés par le contrôleur Token oui non non
Jetons non révélés à l’agent utilisateur oui non non
Le client peut être authentifié [8] oui non oui
Actualisation du jeton d’accès possible oui non oui
Communication en un aller-retour non oui non
La plupart des communications serveur à serveur oui non varie

Choix du flux en fonction de la configuration

Tous les flux n’ont pas la même valeur pour la protection des données confidentielles.
Avant de choisir un flux OpenID Connect, il est important d’identifier la configuration des parties prenantes (applications, serveur OIDC, serveurs de ressource etc.).

Cette problématique est exposée ici : Typologie des applications au regard de la sécurité des données.

Notes

[1Même si les points de terminaison de OAuth 2.0 peuvent être adressés spécifiquement sur le serveur OAuthSD aux URLs https://oa.dnc.global/oauth/...

[2Que le scope openid soit fourni ou non, ce flux Implicite ne retourne pas de jeton d’Identité.

[3Que le scope openid soit fourni ou non, ce flux retourne toujours le jeton d’Identité.

[4Non encore implémenté dans l’état actuel du développement de la librairie OAuth 2.0 Server PHP.

[5Ce flux ne fournit pas le jeton d’actualisation. Voir : http://tools.ietf.org/html/rfc6749#section-4.4.3

[6Ou "Resource Owner Password Credentials Grant Type". Nous citons ce flux, et OAuthSD le met en oeuvre, uniquement par souci de complétude. Ce flux ne doit pas être considéré comme une authentification ; au contraire, l’utilisation de ce flux conduit à une impersonnisation (sur ce sujet, voir : https://www.scottbrady91.com/OAuth/..., nous recommendons donc de ne pas l’utiliser.

[7Cela ressemble beaucoup à l’échange de jeton décrit ici : Un jeton d’identification peut être utilisé pour ... et par cette proposition de standard : Draft IETF : Token Exchange.

[8C’est là l’essence même d’OpenID Connect. Le flux Authorization Code fournit un jeton JWT qui, par sa signature, lie le client, l’utilisateur final et la portée de l’autorisation.

Validation en 2 étapes (Two Factor Authentication, 2FA)

  publié le par DnC

Le nouveau règlement de l’UE exige une authentification de paiement à deux facteurs, appelée « Authentification client forte » (SCA), qui entrera en vigueur en septembre 2019.

Le besoin de la validation à 2 étapes se fait également sentir pour la connexion des utilisateurs aux applications sensibles. Le principe de la validation à 2 étapes (Two Factor Authentication, 2FA) est bien connu depuis plusieurs années et mis en oeuvre de différentes manières, La plus courante étant le code envoyé par SMS.

OAuthSD implémente l’authentification à deux facteurs par SMS ou avec Google Authenticator.

Qu’est-ce que 2FA ?

L’authentification à deux facteurs, également connue sous le nom de 2FA, vérification en deux étapes ou TFA, est une couche de sécurité supplémentaire appelée « authentification à plusieurs facteurs », qui requiert non seulement un mot de passe et un nom d’utilisateur, mais aussi quelque chose que cet utilisateur a sur lui, c’est-à-dire un élément d’information qu’il devrait connaître ou avoir immédiatement sous la main - comme un jeton physique.

Après le login, donnez une deuxième preuve de votre identité

Le processus commence comme d’habitude, l’utilisateur final donnant son identifiant et son mot de passe :

Il lui est demandé de fournir une deuxième preuve d’identité : OAuthSD propose la méthode classique par SMS ou l’identification avec Google Authenticator.

2FA par SMS

Si cette première étape se termine avec succès, OAuthSD enchaîne sur une demande de code par SMS :

Le SMS est envoyé au numéro de smartphone enregistré avec le profil de l’utilisateur [1].

Après confirmation, le consentement est demandé si nécessaire, comme d’habitude :

2FA avec Google Authenticator

Google Authenticator est un système de 2FA qui génère un TOTP.

Qu’est-ce que TOTP ?

TOTP est une forme abrégée de "Time-based One-time Password " ou "mot de passe à utilisation unique à durée déterminée". Il s’agit d’un mot de passe qui ne peut être utilisé qu’une seule fois et qui ne peut être utilisé que dans une plage de temps définie. Généralement, les générateurs TOTP génèrent de nouveaux mots de passe toutes les quelques dizaines de secondes tel que défini.

Après le login, donnez une deuxième preuve de votre identité avec Google Authenticator

Le processus commence comme d’habitude, l’utilisateur final donnant son identifiant et son mot de passe comme précédemment.

Il lui est demandé de fournir une deuxième preuve d’identité : Google Authenticator qu’il ou elle a installé sur son smartphone lui donnera le code nécessaire.

Cela nécessite d’enregistrer OAuthSD sur Google Authenticator en tant qu’application [2]. C’est pour cela que le QRCode est utilisé. Voir de nombreux tutoriels sur le Web. C’est une action unique pour la vie du smartphone : une fois que c’est fait, GA affichera un code toutes les 30 secondes : rien à retenir !

Après confirmation, le consentement est demandé si nécessaire, comme d’habitude.

Pourquoi Google Authenticator ?

Qu’en est-il du suivi (tracking) ? Les applications délèguent l’identification de l’utilisateur à OAuthSD. Cela signifie que Google voit le serveur OAuthSD et non les applications. Google sait qu’un utilisateur est lié à OAuthSD, mais ne voit pas la relation avec l’application ... à condition qu’il n’y ait pas de fuite de suivi ailleurs dans cette application !

Et ensuite ?

D’autres fournisseurs d’identités suivront bientôt, y compris le nôtre (= votre serveur privé) pour une sécurité de niveau supérieur.

Nous pouvons développer tout système privé adapté aux besoins particuliers de nos clients.

Il existe des informations complémentaires, connectez vous pour les voir.

Notes

[1La méthode d’identification par SMS échouera donc si aucun numéro n’a été enregistré pour l’utilisateur qui tente de s’identifier.

[2Notons que c’est bien OAuthSD qui est enregistré sur Google Authenticator, et non les applications clientes. On conserve donc tout l’avantage de la délégation d’authentification pour interdire le tracking de la navigation des utilisateurs finaux.

Le serveur OAuth que DnC met à votre disposition

  publié 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 OAuth2 Server Library for PHP développée par Brent Shaffer (voir : http://bshaffer.github.io/oauth2-se...).

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.
  • Le monitoring de l’état de l’authentification permet à l’utilisateur final de visualiser l’état de la session OIDC. L’utilisateur est averti de l’imminence de la fin de session et peut la prolonger.
  • 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.
  • Des dizaines d’événements différents sont suivis à la microseconde et sont présentés dans des graphes et tableaux interactifs permettant d’identifier avec précision les erreurs et les anomalies significatives d’abus ou de tentative d’intrusion.
  • L’administrateur du serveur est alerté par e-mail des tentatives d’intrusion et des utilisations abusives.
  • 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 avec des données qui permettront 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 !

 

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

  publié le par DnC

Administrateur d’applications, Auteur

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.
Notes :
- cette notion est propre au serveur OAuthSD de DnC.
- il s’agit également d’un objet Auteur au sens de SPIP.

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

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

L’utilisateur est averti des différences pouvant exister entre le serveur OAuthSD et les spécifications d’OpenID Connect : toutes les fonctionnalités ne sont pas nécessairement implémentées par OAuthSD ou ne le sont pas encore, certaines spécifications sont encore à l’état de proposition, certaines fonctionnalités sont jugées peu utiles ou peu sécurisées. De plus, OAuthSD offre quelques extensions intéressantes qui, sans aller à l’encontre du standard, n’en font pas partie. Enfin, OAuthSD est destiné à être mis en oeuvre dans le cadre fermé que constitue un ensemble d’applications d’une même entité ce qui autorise une certaine liberté par rapport aux spécifications.

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.

Politique de diffusion du code

L’objectif de DnC est double :
- 1. Protéger le code spécifiquement créé par DnC et la configuration du serveur OAuthSD afin de rendre plus difficile la tâche des criminels ou malveillants. Pour cela, le code figurant notamment dans les répertoires /vendor/bdegoy/oauthsd-php/src/... est crypté et n’est pas open source mais soumis à une licence particulière.
- 2. Diffuser le plus possible d’information et de code source pour permettre à quiconque d’intégrer dans ses applications la délégation d’authentification et la protection des ressources avec le serveur OAuthSD. Pour cela tout le reste du code, non présent dans les répertoires mentionnés ci-dessus, est diffusé sous licence GPLv3 ou une autre licence Open Source indiquée dans le code, notamment celui en provenance d’autre développeurs.

Cette politique s’applique aussi bien au code présent sur le serveur sous-jacent au présent site web qu’au code déployé chez les utilisateurs d’OAuthSD.

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

RGPD : 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. Nous n’effectuons aucun traitement sur ces données autre que les sauvegardes et ne les diffusons pas.

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.