Accueil > OpenID Connect OAuth Server par DnC > Développer > OpenID Connect > OAuth 2.0 ou OpenID Connect ?

OAuth 2.0 ou OpenID Connect ?

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.