Combien de fois ai-je entendu : “un serveur OAuth2 permet de faire de l’authentification” ? Bon pas tant que ça, mais c’est arrivé plusieurs fois quand même 😄. Je vais essayer d’expliquer dans ce billet pourquoi ça ne sert pas à ça et surtout pourquoi il ne faut surtout pas l’utiliser pour ça.
OAuth2 c’est quoi ?
OAuth2 est un protocole (et/ou framework) de délégation d’autorisation. Il permet d’autoriser une tierce partie d’accéder à ses ressources sans partager pour autant un secret (comme un mot de passe). De plus, il permet également de révoquer cet accès à tout moment.
Par exemple, imaginons que j’ai des documents chez plusieurs prestataires de coffres numériques (Coffreo, Primobox, Lucca, Digipost, …) et que je veux agréger tous ces documents au sein de la même interface. Il va falloir autoriser une autre application à accéder à tous mes coffres. Pour autant, hors de question de partager mon mot de passe avec cette application (sauf si c’est moi qui l’ai faite et que je contrôle la totalité de l’app bien sûr). OAuth2 va me permettre de faire ça.
Autre exemple : j’ai un compte Twitter, mais je préfère utiliser une autre application que l’application officielle. Je peux autoriser une autre application à lire et écrire des tweets pour mon compte.
Bref, il y a vraiment beaucoup d’usages et OAuth2 est aujourd’hui énormément utilisé !
Quel est le problème avec l’authentification alors ?
La principale raison est qu’un access token ne porte pas l’identité d’un utilisateur. Il n’est pas fait pour ça. Un access token permet à son porteur d’accéder à des ressources, c’est tout. Le serveur qui reçoit ce token ne sait même pas de quel utilisateur il s’agit. Il sait juste s’il doit autoriser l’accès ou non. Un access token porte une autorisation.
Un access token n’est en aucun cas une preuve d’autentification. L’utiliser comme base pour initialiser une session utilisateur est donc un choix vraiment désastreux.
Une autre raison (qui découle de la première) est qu’il n’y a rien dans OAuth2 qui standardise l’identité d’un utilisateur, la façon de la récupérer, etc. Donc chacun fait comme il veut et bon courage pour l’interopérabilité.
Prenons un peu de recul, et pensons à ce qu’est un serveur d’authentification : c’est une application qui, après s’être assuré de l’identité d’un utilisateur, doit pourvoir délivrer son identité, être capable de dire si oui ou non, il est connecté, et pour finir mettre fin à sa connexion si besoin. OAuth2 n’est absolument pas capable de faire ça.
Pour finir, il y aurait pas mal à dire sur la faille de sécurité énorme qu’implique l’utilisation d’un access token pour authentifier. Un attaquant qui vole un access token pourrait donc usurper l’identité d’une personne sur tous les applications qui l’utilisent.
L’authentification c’est OpenID Connect
OpenID Connect (OIDC) est une surcouche à OAuth2 dédiée à l’authentification. Il repose entièrement sur OAuth2 et lui ajoute un usage : l’authentification. La plupart du temps d’ailleurs, OIDC est déployé en même temps qu’OAuth2.
A priori, tout le monde (ou presque) a déjà utilisé un serveur OIDC puisque France Connect est une implémentation de OIDC. France Connect est l’application qui permet d’accéder aux services de l’état comme Ameli (l’assurance maladie), le site des impôts, etc.
OIDC introduit un jeton appelé id token qui est un JWT et qui va porter les informations de l’utilisateur connecté et de sa session. De plus, OIDC étant un standard, la structure d’un id token est également standard : vive l’interopérabilité !
Toujours sur le même sujet de la standardisation, OIDC fournit un endpoint dédié à fournir des informations sur l’utilisateur connecté. On n’est pas sur une API “custom” où tout le monde fait “à sa sauce”.
Conclusion
Chaque technologie, framework, etc vient avec son/ses usages. Ne pas respecter ça, c’est s’exposer à des problèmes. Et concernant ce qui touche à la sécurité de nos applications (authentification, autorisation, …), on préfère éviter les problèmes.
Ce billet se concentre sur pourquoi on ne doit pas utiliser OAuth2 pour faire de l’authentification mais ne vise clairement pas à expliquer en détails OAuth2 et OIDC. Si le sujet vous intéresse, je vous conseille 2 très bonnes présentations (récentes) :