Accueil > OpenID Connect OAuth Serveur dédié > 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’identification de l’utilisateur final n’est pas transmise à l’application), mais un système d’autorisation. De plus, la sécurité d’OAuth 2.0 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.

- 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). Le fait que la nécessité de vérifier le jeton n’est pas mentionnée dans la spécification ouvre la porte à des développements insuffisamment sécurisés.

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

OAuthSD applique la proposition de standard RFC 7662 : OAuth 2.0 Token Introspection. OAuthSD expose un point d’entrée d’introspection qui permet de vérifier aussi bien les jetons d’accès d’OAuth 2.0 que les jetons d’identité d’OpenID Connect.

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é ou JWS [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, vérifier 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 appliqué à des applications clientes de type web (avec back-end) peut être considéré comme sûr. Voyez : Typologie des applications au regard de la sécurité des données.

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 mais sans oublier l’introspection) et OpenID Connect comme un protocole construit sur OAuth 2.0.

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, y compris pour des applications mobiles ou de desktop, 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)".