Souvent confondu avec le openid, je vais m’intéresser, dans cet article, au protocole OAuth.
Si vous avez un site ecommerce, vous avez probablement des méthodes de connexions clients. Et il y a de fortes chances que ces connexions soient liées à de la donnée personnelle.
Dans ce cas attention, une très grande partie des cyber attaques cibles les PME car elles ne dédient pas suffisamment de budget à la protection des données.
Cependant, il y a des solutions, et OAuth fait partie de celles-ci.
Si vous vous intéressez à la connexion entre des outils via API, à la sécurisation de la connexion de vos utilisateurs ou à tout autre forme de délégation.
Vous devez absolument vous intéresser au protocole OAuth afin de comprendre son fonctionnement et ses principaux objectifs.
Enfin, après avoir lu cet article, vous pourrez facilement différencier l’openid du OAuth. Et ça ce n’est pas donnée à tous le monde 😉
Un monde d’API
Que ce soit pour les ecommercants avec le headless commerce , pour la productivité avec des outils nocode, pour réaliser des connexions avec l’openid ou tout simplement pour connecter deux de vos logiciels informatiques.
Les API sont devenu un incontournable dans le monde des nouvelles technologies…
Mais voila, les échanges API sont une chose mais il manque un point important dans tout ca. Et c’est la sécurité !
Et là, protocole OAuth est né
OAuth est un protocole libre (créé en 2006 ca commence à faire) qui permet d’autoriser un logiciel ou une application (que l’on appellera le consommateur) à utiliser l’API de manière sécurisé à un autre site ou logiciel (dit « fournisseur »).
Un point important à comprendre est que le protocole OAuth n’est pas un protocole d’authentification mais de « délégation d’autorisation ». Gardez cela en tête on y reviendra plus tard dans cet article 😉
OAuth comment ca marche ?
OAuth dans sa nouvelle version 2.0, repose sur des échanges entre 4 acteurs.
- Le resource owner (l’utilisateur), c’est l’acteur qui aura la capacité d’accorder l’accès à la ressource pour une application client.
- L’application client, sera l’application qui présentera au ressource owner l’accès.
- L’authorization server (le serveur d’autorisation), c’est l’acteur qui sera en charge d’authentifier le resource owner et de lui fournir le « jeton » (token) permettant de délivrer l’autorisation d’accès.
- Le resource server quant à lui correspond au serveur où sont stockés les ressources protégées.
Les avantages du OAuth
Il y a plusieurs avantages à ce mécanisme :
- Pour un protocole de sécurisé, OAuth est simple d’implémentation. Et ca ca fait plaisir 😊
- Etant donné que, ce protocole permet l’échange du jeton d’accès (token) par un canal contrôlé par deux services. L’interception des requêtes par un hacker ne servira à rien. C’est donc un bon protocole de sécurité.
- Même si le serveur sur lequel travail les développeurs n’a pas de certificat SSL. Il pourra faire appel à d’autres protocoles d’échanges sécurisés pour l’échange du token.
- Enfin, Il est possible de signer et/ou d’ajouter une date de péremption aux jetons d’accès. Pour ajouter encore plus de sécurité.
OpenID et OAuth ?
Alors c’est quoi cette fameuse différence entre l’openid et le protocole OAuth.
Et bien il faut revenir à la définition présentée en haut de cet article, OAuth n’est pas un protocole d’authentification mais de « délégation d’autorisation.
Cependant OpenID lui, est bien un protocole d’authentification.
Et c’est pour cela que nous avons souvent tendance à confondre les deux.
En réalité OpenID est une couche supplémentaire qui utilise OAuth pour réaliser de l’identification.
Et je suis sur que vous connaissez de très nombreux sites qui utilisent déja de l’OpenID.
Vous pouvez prendre comme exemple la connexion avec facebook ou google. Certains sites ecommerces font le choix de déléguer l’autorisation à ces marques via de l’OpenID.
En conclusion
J’espère que vous avec maintenant compris que le protocole OAuth est un incontournable dans les protocoles d’échanges entre les API. En particulier lorsque vous réalisez des flux d’échanges avec les données personnelles.
Vous l’aurez compris, OpenID n’est qu’une couche supplémentaire qui viendra utiliser le protocole OAuth afin de permettre l’authentification des clients.
