OAuth

Cet article est une ébauche concernant la sécurité informatique.

Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.

OAuth

Logo d'OAuth

Informations
Fonction	Autorisation
Date de création	2007
RFC	2010 : 5849 2012 : 6749, 6750

OAuth est un protocole libre qui permet d'autoriser un site web, un logiciel ou une application (dite « consommateur ») à utiliser l'API sécurisée d'un autre site web (dit « fournisseur ») pour le compte d'un utilisateur. OAuth n'est pas un protocole d'authentification, mais de « délégation d'autorisation ».

OAuth permet à l'utilisateur de donner, au site ou logiciel « consommateur », l'accès à ses informations personnelles qu'il a stockées sur le site « fournisseur » de service ou de données, ceci tout en protégeant le pseudonyme et le mot de passe des utilisateurs. Par exemple, un site de manipulation de vidéos pourra éditer les vidéos enregistrées sur Dailymotion d'un utilisateur des deux sites, à sa demande.

Le protocole est créé par Blaine Cook et Chris Messina (en) et sa partie principale, OAuth Core 1.0, est finalisée le 3 octobre 2007.

Histoire modifier

OAuth a commencé en novembre 2006, alors que Blaine Cook implémentait OpenID pour Twitter. Avec Chris Messina, ils rencontrèrent David Recordon et Larry Halff pour discuter de la possibilité d'utiliser OpenID et l'API de Twitter pour déléguer l'authentification. Ils conclurent qu'il n'y avait pas de standard ouvert pour la délégation d'accès par API.

Un groupe de travail a été créé en avril 2007 pour rédiger un premier jet de proposition pour un protocole ouvert. DeWitt Clinton de Google fut informé du projet OAuth et affirma sa volonté de soutenir le standard. En juillet 2007, l'équipe rédigea les premières spécifications à l'état de draft (brouillon). Le 3 octobre 2007, la version OAuth Core 1.0 était publiée.

Le 24 juin 2009, la version OAuth Core 1.0a venait corriger une faille de sécurité.

En avril 2010, la RFC 5849 standardise OAuth 1.0a.

En octobre 2012, les RFC 6749 et RFC 6750 standardisent OAuth 2.0.

Mode de fonctionnement modifier

Workflow d’utilisation de OAuth 2.0

OAuth dans sa version 2.0^[1] repose sur des échanges entre quatre acteurs. Le resource owner (utilisateur) est capable d’accorder l’accès à la ressource pour une application client. L’authorization server (serveur d’autorisation) occupe le rôle central au sein du protocole, il est chargé d’authentifier le resource owner et de délivrer son autorisation sous la forme d’un jeton appelé access token. Le resource server quant à lui correspond au serveur où sont stockées les ressources protégées^[2].

Lorsque l'application cliente souhaite demander une ressource à l'utilisateur, il envoie une requête au serveur d’autorisation composé à la fois d'une adresse URI de retour et d'un scope. Le scope définit le type et le périmètre des ressources demandées. Sur cette base, le serveur d’autorisation authentifie l'utilisateur et recueille son consentement pour la transmission de la ressource. Le serveur d’autorisation va envoyer un authorization code au client en paramètre de l'adresse URI de retour. Lorsque l'utilisateur se connecte à cette URI complétée de l’authorization code, le client renvoie l'authorization code au serveur d’autorisation pour se voir fournir un access token (jeton d'accès). Finalement, le client envoie le jeton d'accès au resource server pour obtenir les ressources de l'utilisateur.

Ce mécanisme^[3] de va-et-vient avec l’authorization code et jeton d'accès a plusieurs avantages :

il respecte une convention de type sécurité backend^[4]. La machine cliente est jugée peu sécurisée. En cas d'interception des requêtes sur cette dernière, l’authorization code ne permet pas de récupérer les ressources de l'utilisateur. L'échange du jeton d'accès se fait par un canal contrôlé par les deux services professionnels.
oAuth permet ainsi aux développeurs, n'ayant pas de serveur avec certificat SSL proprement configuré, de faire appel à d'autres protocoles d'échange sécurisés que HTTPS pour l'échange du jeton d'accès.
les jetons d'accès^[5] (comme les JSON Web Token) peuvent être signés par le serveur d’autorisation. Ils peuvent également contenir une date de péremption.

Notes et références modifier

↑ « OAuth 2.0 — OAuth », sur oauth.net (consulté le 8 septembre 2020)
↑ « Sécurisez l’accès à vos APIs avec OAuth2 », sur Nexworld, 12 juillet 2018 (consulté le 26 février 2020)
↑ (en) Nilasini Thirunavukkarasu, « Id token Vs access token », sur Medium, 30 juin 2018 (consulté le 7 janvier 2021)
↑ (en) « TeskaLabs Blog· Understanding the Importance and Value of Backend Security », sur TeskaLabs Blog (consulté le 7 janvier 2021)
↑ (en) Dick Hardt, « The OAuth 2.0 Authorization Framework », sur tools.ietf.org (consulté le 7 janvier 2021)

Voir aussi modifier

Articles connexes modifier

Liens externes modifier

(en) Site officiel
(en) DataPortability.org
(en) Tutoriel : Surveillance d'un système Linux en temps réel sur Twitter avec sécurité OAuth
RFC 5849, The OAuth 1.0 Protocol
RFC 6749, The OAuth 2.0 Authorization Framework
RFC 6750, The OAuth 2.0 Authorization Framework: Bearer Token Usage

Portail de la sécurité informatique

[1] « OAuth 2.0 — OAuth », sur oauth.net (consulté le 8 septembre 2020)

[2] « Sécurisez l’accès à vos APIs avec OAuth2 », sur Nexworld, 12 juillet 2018 (consulté le 26 février 2020)

[3] (en) Nilasini Thirunavukkarasu, « Id token Vs access token », sur Medium, 30 juin 2018 (consulté le 7 janvier 2021)

[4] (en) « TeskaLabs Blog· Understanding the Importance and Value of Backend Security », sur TeskaLabs Blog (consulté le 7 janvier 2021)

[5] (en) Dick Hardt, « The OAuth 2.0 Authorization Framework », sur tools.ietf.org (consulté le 7 janvier 2021)

[1]

[2]

[3]

[4]

[5]