OAuth

OAuth est un cadre de norme ouverte pour l'autorisation des API. Il définit comment un client d'API peut obtenir des jetons de sécurité exprimant un ensemble d'autorisations pour les ressources gérées par cette API. Ces autorisations reflètent souvent le consentement de l'utilisateur qui possède ces ressources. Les jetons sont joints par le client à ses messages API pour servir de preuve des autorisations du client par rapport aux demandes qu'il adresse aux ressources.

Au lieu d'exiger d'un utilisateur qu'il partage ses identifiants de connexion avec une application pour permettre à cette application d'accéder à une autre, OAuth délègue les décisions d'autorisation à un serveur d'autorisation distinct qui héberge le compte de l'utilisateur. Essentiellement, OAuth agit au nom de l'utilisateur, en fournissant un accès délégué à un service tiers sans que l'utilisateur expose ses identifiants à ce tiers.

Par exemple, si vous créez un compte sur YouTube et que YouTube vous offre la possibilité de vous connecter avec vos identifiants Google, vous pouvez être autorisé(e) à accéder aux ressources de YouTube avec ces identifiants sans jamais avoir à les fournir.

Remarque : OAuth 1.0a et OAuth 2.0 sont les deux versions différentes disponibles. Elles sont différentes, ne peuvent pas être utilisés ensemble et ne sont pas rétrocompatibles. Cependant, la plupart des gens utilisent aujourd'hui OAuth 2.0, c'est donc la version que nous aborderons ici. 

Le processus d'enregistrement dans un hôtel est un autre exemple illustrant le fonctionnement d'OAuth. Vous vous rendez à la réception et vous vous authentifiez en présentant votre pièce d'identité. Une fois que vous avez prouvé votre identité, le concierge à la réception échange ces informations contre une carte-clé de l'hôtel.

Votre carte-clé vous permet d'accéder à votre chambre, ainsi qu'à la piscine et à la salle de remise en forme. Cependant, vous ne pourrez pas accéder aux placards de conciergerie pour récupérer des serviettes supplémentaires, car vous n'avez pas l'autorisation. 

Le processus d’enregistrement à l’hôtel est similaire au processus d’autorisation OAuth :

• L'hôtel peut révoquer votre accès à tout moment, tout comme le serveur d'autorisation peut révoquer l'accès à tout moment.
  
  
• Votre carte-clé ne contient pas votre identité ni vos identifiants, tout comme le jeton d’accès accordé par le serveur d’autorisation ne nécessite pas d’inclure des informations sur l’utilisateur.
  
  
• Vous pouvez utiliser votre carte-clé pour accéder à plusieurs ressources de l'hôtel. De la même manière, le jeton d'accès vous permet d'accéder à des ressources spécifiques et interdit l'accès à d'autres.
  
  
• Votre carte-clé expirera lorsque vous quitterez l'hôtel. Votre jeton d'accès OAuth expirera également.
  

Comment fonctionne OAuth ?

Les utilisateurs donnent à une application l'autorisation d'accéder aux données d'une autre application sans avoir à fournir leurs noms d'utilisateur et mots de passe. Au lieu de cela, les jetons d'accès sont utilisés pour compléter le processus d'autorisation.

Ces jetons contiennent des informations sur la session d'authentification, l'identifiant de l'utilisateur, un identifiant du fournisseur d'identité qui a émis le jeton, et un identifiant du client pour lequel le jeton a été créé. Les jetons contiennent également des informations sur la durée de leur validité et sur le temps écoulé à compter du début du processus d'autorisation. 

Avec OAuth, il y a quatre rôles différents :
 

• Propriétaire de la ressource : le propriétaire de la ressource, c'est vous. Vous êtes propriétaire de vos données et vous autorisez une application à accéder aux informations de votre compte. 
   

• Client : le client est l'application qui souhaite accéder aux informations de votre compte. Avant qu'il ne puisse accéder à ces informations, vous devez l'autoriser, et l'autorisation doit être validée par l'API.
   

• Serveur de ressources : le serveur de ressources héberge les informations de compte utilisateur protégées.
   

• Serveur d'autorisation : le serveur d'autorisation vérifie l'identité de l'utilisateur, puis délivre des jetons d'accès à l'application.

Il existe différents types de flux OAuth disponibles, mais voici comment fonctionnent les flux OAuth de manière générale :

1. Lorsque vous vous connectez à une application, vous êtes invité à autoriser ou à refuser l'accès de l'application cliente aux informations de votre compte. 
   
   
2. Lorsque vous autorisez la demande, l'application cliente reçoit un code d'autorisation.
   
   
3. L'application présente l'authentification de son identité propre, le code d'autorisation au serveur d'autorisation, et demande un jeton d'accès.
   
   
4. Si l'application est authentifiée et que le code d'autorisation est valide, le serveur d'autorisation émet un jeton d'accès à l'application. Les jetons d'accès sont similaires à des badges ou à des cartes-clés qui donnent au client l'autorisation d'effectuer des actions spécifiques en votre nom. Les champs d'application sont inclus dans le jeton et définissent ces autorisations.
   
   
5. L'application demande les ressources à l'API du serveur de ressources et présente le jeton d'accès.
   
   
6. Si le jeton d'accès est valide, l'API du serveur de ressources fournit à l'utilisateur une URI de redirection qui permet d'accéder à l'application et aux ressources appropriées.
   
   

OAuth n'est pas un protocole d'authentification

OAuth est utilisé dans une grande variété d'applications et de différentes manières, c'est pourquoi beaucoup de gens pensent qu'il s'agit d'un protocole d'authentification, mais ce n'est pas le cas. C'est même mentionné sur leur site. 

L'origine de la confusion vient du fait qu'OAuth est utilisé à l'intérieur de protocoles d'authentification, et les développeurs verront les composants OAuth et interagiront avec le flux OAuth et supposeront qu'en utilisant OAuth, ils peuvent authentifier leurs utilisateurs. 

Cependant, il existe de nombreuses façons différentes d'utiliser OAuth. OAuth ne définit pas un format de jeton spécifique ni un ensemble commun de champs d'application pour le jeton d'accès, il ne traite pas de la manière dont une ressource protégée valide un jeton d'accès, et les fournisseurs d'identité mettent en œuvre l'identité API différemment, de sorte qu'un code personnalisé peut être nécessaire pour l'implémentation avec les vendeurs.

Par exemple, l'identifiant d'un utilisateur peut être trouvé dans le champ user_id chez un fournisseur, mais dans le champ subject chez un autre fournisseur. Même si ces identifiants sont sémantiquement identiques, ils nécessiteraient deux chemins de code distincts pour être traités. En d'autres termes, même si l'autorisation peut se faire de la même manière chez chaque fournisseur, les manières dont elles sont transmises peuvent être différentes.