Cet article est uneébauche concernant lasécurité informatique.
| Fonction | Autorisation |
|---|---|
| Date de création | 2007 |
| RFC | 2010 :5849 2012 :6749,6750 |
OAuth est unprotocole libre qui permet d'autoriser unsite 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 lepseudonyme et le mot de passe des utilisateurs. Par exemple, un site de manipulation de vidéos pourra éditer les vidéos enregistrées surDailymotion d'un utilisateur des deux sites, à sa demande.
Le protocole est créé parBlaine Cook etChris Messina (en) et sa partie principale, OAuth Core 1.0, est finalisée le.
OAuth a commencé en, alors que Blaine Cook implémentaitOpenID pourTwitter. Avec Chris Messina, ils rencontrèrent David Recordon et Larry Halff pour discuter de la possibilité d'utiliser OpenID et l'API deTwitter pour déléguer l'authentification. Ils conclurent qu'il n'y avait pas destandard ouvert pour la délégation d'accès par API.
Un groupe de travail a été créé en pour rédiger un premier jet de proposition pour un protocole ouvert. DeWitt Clinton deGoogle fut informé du projet OAuth et affirma sa volonté de soutenir le standard. En, l'équipe rédigea les premières spécifications à l'état dedraft (brouillon). Le, la version OAuth Core 1.0 était publiée.
Le, la version OAuth Core 1.0a venait corriger unefaille de sécurité.
En, laRFC 5849 standardise OAuth 1.0a.
En, lesRFC 6749 etRFC 6750 standardisent OAuth 2.0.
OAuth dans sa version 2.0[1] repose sur des échanges entre quatre acteurs. Leresource owner (utilisateur) est capable d’accorder l’accès à la ressource pour une applicationclient. L’authorization server (serveur d’autorisation) occupe le rôle central au sein du protocole, il est chargé d’authentifier leresource owner et de délivrer son autorisation sous la forme d’un jeton appeléaccess token. Leresource 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 adresseURI de retour et d'unscope. Lescope 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 unauthorization 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 unaccess token (jeton d'accès). Enfin, le client envoie le jeton d'accès auresource 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 :
Des implémentations clientes en logiciels libres du protocole OAuth2 telles que l'extensionLibreOfficeOAuth2OOo vous permettront d'accéder à des ressources distantes (via l'API Google ou l'APIMicrosoft Graph (en) et OAuth 2.0) et ce même éventuellement avec le langageBasic de LibreOffice. Cela rend très facile l'écriture et l'utilisation de requêtes HTTP supportant le protocole OAuth 2.0 dans desmacros LibreOffice.
