OAuth

OAuth, désormais connu comme OAuth 2.0, est un modèle de standard ouvert pour l’autorisation des API. Il définit la façon dont un API client obtient des jetons de sécurité qui contiennent un ensemble de permissions concernant les ressources accessibles par l’API en question. Ces permissions reflètent souvent le consentement de l’utilisateur qui détient ces ressources. Ces jetons sont attachés par le client à ses messages d’API pour servir de preuve des autorisations du client relatives aux requêtes qu’elle fait sur les ressources.

Au lieu de demander à un utilisateur de partager ses identifiants de connexion avec une application pour que cette application puisse 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. En bref, 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.

Au lieu de demander à un utilisateur de partager ses identifiants de connexion avec une application pour que cette application puisse 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. En bref, 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.

Remarque : OAuth 1.0a et OAuth 2.0 sont les deux spécifications différentes disponibles. Les deux sont différentes, ne peuvent pas être utilisées ensemble et ne sont pas rétroactivement compatibles. Mais étant donné qu’aujourd’hui la plupart des gens utilisent OAuth 2.0, c’est la spécification que nous évoquons ici.  

La procédure d’enregistrement à l’hôtel est un autre exemple de fonctionnement de OAuth. Vous allez à l’accueil et vous vous authentifiez en fournissant votre pièce d’identité. Une fois que vous avez prouvé qui vous êtes, le concierge, à l’accueil, é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 sport. Toutefois, vous ne pourrez pas accéder aux placards de rangement pour avoir des serviettes supplémentaires car vous n’en avez pas l’autorisation. 

Le processus d’enregistrement dans l’hôtel ressemble 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.
  
  
• Ni votre identité ni vos identifiants ne figurent sur la carte-clé. De la même manière, le jeton d’accès accordé par le serveur d’autorisation n’a pas besoin d’inclure les informations de l’utilisateur.
  
  
• Vous pouvez utiliser votre carte-clé pour accéder à de multiples ressources de l’hôtel. De même, le jeton d’accès vous laisse accéder à des ressources spécifiques et vous refuse l’accès à d’autres ressources.
  
  
• Votre carte-clé expirera quand vous quitterez l’hôtel. Votre jeton d’accès OAuth va aussi expirer.

Fonctionnement de OAuth

Les utilisateurs donnent à une application une permission pour accéder à des données sur une autre application sans devoir fournir leur nom d’utilisateur ni leur mot de passe. Au lieu de cela, des jetons d’accès sont utilisés pour réaliser le processus d’autorisation.

Ces jetons contiennent des informations sur la session d’authentification, un identifiant pour l’utilisateur, un identifiant pour le fournisseur d’identité qui a délivré le jeton, et un identifiant pour le client pour lequel le jeton a été créé. Les jetons contiennent aussi des informations sur la durée pendant laquelle ils seront valables et le temps qui s’est écoulé depuis le début du processus d’autorisation. 

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

• Propriétaire de la ressource : Vous êtes le propriétaire de la ressource. 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’elle puisse accéder à ces informations, vous devez donner votre autorisation, et cette autorisation doit être validée par l’API.
   

• Serveur de la ressource : Le serveur de la ressource héberge les informations du compte utilisateur.
   

• Serveur d’autorisation : Le serveur d’autorisation vérifie l’identité de l’utilisateur avant de délivrer les jetons d’accès à l’application.

Plusieurs types de flux OAuth différents sont disponibles, mais le diagramme ci-dessous explique comment les flux OAuth fonctionnent à un niveau élevé.  

1. Lorsque vous vous connectez à une application, vous êtes invité à autoriser ou refuser l’accès de l’application client aux informations de votre compte.  
   
   
2. Lorsque vous autorisez la demande, l’application client reçoit un code d’autorisation.
   
   
3. L’application présente l’authentification de sa propre identité, 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 délivre un jeton d’accès à l’application. Les jetons d’accès ressemblent à des badges ou à des cartes-clés qui donnent au client la permission de réaliser des actions spécifiques en votre nom. Les portées figurent sur le jeton et définissent ces permissions.
   
   
5. L’application demande les ressources à l’API du serveur des ressources et présente le jeton d’accès.
   
   
6. Si le jeton d’accès est valide, l’API du serveur de ressource procure à l’utilisateur une URI de redirection qui donne accès à l’application et aux ressources appropriées.
   
   

OAuth n’est pas un protocole d’authentification

OAuth est utilisé dans un large éventail d’applications et il est utilisé de diverses manières ; c’est pourquoi beaucoup de gens pensent qu’il s’agit d’un protocole d’authentification même si ce n’est pas le cas. C’est également précisé sur son site. 

La confusion découle en grande partie du fait que OAuth est utilisé dans les protocoles d’authentification, et les développeurs verront les composants de OAuth, interagiront avec le flux OAuth et assumeront qu’en utilisant OAuth ils pourront authentifier leurs utilisateurs. 

Mais OAuth peut être utilisé de plusieurs manière différentes. OAuth ne définit pas un format de jeton spécifique ou un ensemble commun de portées pour le jeton d’accès ; il ne concerne pas la manière dont une ressource protégée valide un jeton d’accès et les fournisseurs d’identité mettent en place l’identité de l’API différemment, de sorte qu’un code personnalisé puisse être nécessaire pour s’intégrer aux fournisseurs.

Par exemple, ce qui identifie un utilisateur peut se trouver dans un champ user_id avec un fournisseur mais dans le champ sujet chez un autre fournisseur. Bien que ces identifiants soient sémantiquement les mêmes, il leur faudrait deux chemins de codes distincts pour être traités. Dit autrement, si une autorisation peut avoir lieu de la même manière avec chaque fournisseur, la manière dont elle est acheminée pourrait être différente.