OAuth 2.0: avantages et cas d'utilisation-pourquoi?

Contexte: j'ai écrit des piles client et serveur pour OAuth 1.0 A et 2.0.

Deux OAuth 1.0 a et 2.0 deux pattes d'authentification, où un serveur est assuré de l'identité d'un utilisateur, et trois-pattes d'authentification, où un serveur est assurée par un fournisseur de contenu de l'identité de l'utilisateur. L'authentification à trois pattes est l'endroit où les demandes d'autorisation et les jetons d'accès entrent en jeu, et il est important de noter que OAuth 1 les a aussi.

Le complexe un: authentification à trois pattes

Un point principal des spécifications OAuth est pour un fournisseur de contenu (par exemple Facebook, Twitter,etc.) pour assurer un serveur (par exemple une application Web qui souhaite parler au fournisseur de contenu au nom du client) que le client a une certaine identité. Ce que l'authentification à trois pattes offre, c'est la possibilité de le faire sans que le client ou le serveur n'ait jamais besoin de connaître les détails de cette identité (par exemple, Nom d'utilisateur et mot de passe).

Sans (?) entrer trop profondément dans les détails de OAuth:

1. le client soumet une demande d'autorisation au serveur, qui valide que le client est un client légitime de son service.
2. Le serveur redirige le client vers le fournisseur de contenu pour demander l'accès à ses ressources.
3. le fournisseur de contenu valide l'identité de l'utilisateur et lui demande souvent l'autorisation d'accéder aux ressources.
4. le fournisseur de contenu redirige le client vers serveur, l'informant du succès ou de l'échec. Cette demande comprend un code d'autorisation en cas de succès.
5. le serveur fait une demande hors bande au fournisseur de contenu et échange le code d'autorisation contre un jeton d'accès.

Le serveur peut maintenant faire des requêtes au fournisseur de contenu au nom de l'utilisateur en passant le jeton d'accès.

Chaque échange (client->Serveur, Serveur->fournisseur de contenu) inclut la validation d'un secret partagé, mais puisque OAuth 1 peut s'exécuter une connexion non cryptée, chaque validation ne peut pas passer le secret sur le fil.

C'est fait, comme vous l'avez noté, avec HMAC. Le client utilise le secret qu'il partage avec le serveur pour signer les arguments de sa demande d'autorisation. Le serveur prend les arguments, les signe lui-même avec la clé du client et est capable de voir s'il s'agit d'un client légitime (à l'étape 1 ci-dessus).

Cette signature nécessite que le client et le serveur s'accordent sur l'ordre des arguments (donc ils signent exactement la même chaîne), et L'une des principales plaintes concernant OAuth 1 est qu'il nécessite à la fois le serveur et les clients pour trier et signer de manière identique. C'est du code fiddly et soit c'est juste, soit vous obtenez 401 Unauthorized avec peu d'aide. Cela augmente la barrière à l'écriture d'un client.

En exigeant que la demande d'autorisation s'exécute sur SSL, OAuth 2.0 supprime complètement le besoin de tri et de signature des arguments. Le client transmet son secret au serveur, qui le valide directement.

Les mêmes exigences sont présentes dans la connexion server->content provider, et puisque C'est SSL qui supprime une barrière à l'écriture d'un serveur qui accède aux services OAuth.

Cela rend les choses beaucoup plus faciles dans les étapes 1, 2 et 5 ci-dessus.

Donc, à ce stade, notre serveur a un jeton d'accès permanent qui est un nom d'utilisateur/mot de passe équivalent pour l'utilisateur. Il peut faire des demandes au fournisseur de contenu au nom de l'utilisateur en passant ce jeton d'accès dans le cadre de la requête (en tant qu'argument de requête, en-tête HTTP ou données de formulaire POST).

Si le service de contenu est accessible uniquement via SSL, nous avons terminé. S'il est disponible via HTTP ordinaire, nous aimerions protéger ce jeton d'accès permanent d'une manière ou d'une autre. Toute personne reniflant la connexion serait en mesure d'avoir accès au contenu de l'utilisateur pour toujours.

La façon qui est résolue dans OAuth 2 est avec un jeton refresh . Le jeton d'actualisation devient l'équivalent permanent du mot de passe, et il n'est transmis que par sur SSL . Lorsque le serveur a besoin d'accéder au service de contenu, il échange le jeton d'actualisation contre un jeton d'accès de courte durée. De cette façon, tous les accès HTTP reniflables sont effectués avec un jeton qui expirera. Google utilise une expiration de 5 minutes sur leurs API OAuth 2.

Ainsi, en dehors des jetons d'actualisation, OAuth 2 simplifie toutes les communications entre le client, le serveur et le fournisseur de contenu. Et les jetons d'actualisation n'existent que pour assurer la sécurité lorsque le contenu est accessible chiffrer.

Authentification à deux pattes

Parfois, cependant, un serveur a juste besoin de contrôler l'accès à son propre contenu. L'authentification à deux pattes permet au client d'authentifier l'utilisateur directement avec le serveur.

OAuth 2 standardise certaines extensions à OAuth 1 qui étaient largement utilisées. Celui que je connais le mieux a été introduit par Twitter comme xAuth. Vous pouvez le voir dans OAuth 2 comme informations D'Identification du mot de passe du propriétaire de la ressource .

Essentiellement, si vous le pouvez la confiance du client avec les informations d'identification utilisateur (nom d'utilisateur et mot de passe), ils peuvent échanger directement avec le fournisseur de contenu pour un jeton d'accès. Cela rend OAuth beaucoup plus utile sur les applications mobiles-avec l'authentification à trois pattes, vous devez intégrer une vue HTTP afin de gérer le processus d'autorisation avec le serveur de contenu.

Avec OAuth 1, cela ne faisait pas partie de la norme officielle et nécessitait la même procédure de signature que toutes les autres demandes.

J'ai juste implémenté le côté serveur D'OAuth 2 avec les informations d'Identification du mot de passe du propriétaire de la ressource, et du point de vue du client, obtenir le jeton d'accès est devenu simple: demander un jeton d'accès au serveur, passer l'id/secret du client en tant qu'en-tête D'autorisation HTTP et le login/mot de passe de

Avantage: Simplicité

Donc, du point de vue d'un implémenteur, les principaux avantages que je vois dans OAuth 2 sont d'une complexité réduite. Il ne nécessite pas la signature de la demande la procédure, qui n'est pas exactement difficile, mais n'est certainement délicat. Cela réduit considérablement le travail requis pour agir en tant que client d'un service, ce qui est l'endroit (dans le monde moderne et mobile) où vous voulez le plus minimiser la douleur. La complexité réduite à la fin du serveur->fournisseur de contenu le rend plus évolutif dans le centre de données.

Et il codifie dans la norme certaines extensions d'OAuth 1.0 a (comme xAuth) qui sont maintenant largement utilisées.