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

Question

Quelqu'un pourrait-il expliquer ce qui est bon au sujet de OAuth2 et pourquoi devrions-nous mettre en œuvre? Je demande parce que je suis un peu confus à ce sujet - là de mes pensées:

OAuth1 (plus précisément HMAC) les demandes sembler logique, facile à comprendre, facile à développer et vraiment, vraiment sécurisé.

OAuth2, au lieu de cela, apporte les demandes d'autorisation, les jetons d'accès et d'actualisation des jetons, et vous devez effectuer 3 demandes au tout début d'une session pour obtenir les données que vous êtes après. Et même alors, l'une de vos demandes finira par défaut lors de l'expiration de ce jeton.

Et pour obtenir un autre jeton d'accès, vous utilisez un jeton d'actualisation qui a été adoptée en même temps que le jeton d'accès. Est-ce que le jeton d'accès futile à partir d'un point de vue sécurité?

De Plus, comme /r/netsec ont montré récemment, SSL n'est pas entièrement sécurisés, afin de les pousser à le faire tout sur TLS/SSL au lieu de sûr HMAC me confond.

OAuth font valoir qu'il n'est pas question de la sécurité à 100%, mais il a publié et c'est fini. Ce n'est pas vraiment sembler prometteur partir d'un fournisseur de point de vue. Je peux voir ce que le projet est en train d'essayer de réaliser quand il mentionne les 6 différents flux, mais c'est juste pas s'emboîtent dans ma tête.

Je pense qu'il pourrait être de plus en plus ma difficulté à comprendre les bénéfices et le raisonnement que le fait de ne pas aimer, et c'est peut-être un peu d'une attaque injustifiée contre, et désolé si cela peut sembler comme un coup de gueule.

Answer 1

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

Les deux OAuth 1.0 a et 2.0 de soutien à 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. Trois-pattes d'authentification est là que les demandes d'autorisation et les jetons d'accès entrent en jeu, et il est important de noter que le protocole OAuth 1 a ceux, trop.

Le complexe: trois-pattes d'authentification

Un point principal de l'OAuth des specs, c'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 de la part du client) que le client a une certaine identité. Quelles sont les trois pattes d'authentification est la possibilité de le faire sans que le client ou le serveur jamais avoir besoin de connaître les détails de cette identité (par exemple, nom d'utilisateur et mot de passe).

Sans (?) trop profondément dans les détails de l'authentification OAuth:

1. Le client soumet une demande d'autorisation au serveur, ce qui permet de vérifier que le client est légitime client 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 souvent des demandes d'autorisation d'accès aux ressources.
4. Le fournisseur de contenu redirige le client vers le serveur, en le notifiant de la réussite ou de l'échec. Cette demande comprend un code d'autorisation sur la réussite.
5. Le serveur effectue un out-of-band demande au fournisseur de contenu et d'échanges le code d'autorisation pour un jeton d'accès.

Le serveur peut maintenant faire la demande auprès du fournisseur de contenu pour le compte de l'utilisateur en passant par le jeton d'accès.

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

C'est fait, comme vous l'avez remarqué, HMAC. Le client utilise le secret qu'il partage avec le serveur de signer les arguments en faveur de sa demande d'autorisation. Le serveur prend les arguments, le signe lui-même avec le client est la clé, et est en mesure de voir si c'est légitime client (à l'étape 1 ci-dessus).

Cette signature implique à la fois le client et le serveur d'accord sur l'ordre des arguments (ils sont donc la signature exactement la même chaîne), et l'une des principales plaintes au sujet de OAuth 1 est qu'il exige à la fois le serveur et les clients de trier et de signe identique. C'est délicat de code et que ce soit à droite ou que vous avez des 401 Unauthorized avec un peu d'aide. Cela augmente la barrière de l'écriture d'un client.

En exigeant que la demande d'autorisation d'exécuter sur SSL, le protocole OAuth 2.0 supprime la nécessité pour l'argument de tri et de signature tout à fait. Le client passe son secret pour le serveur, qui le valide directement.

Les mêmes exigences sont présents dans le serveur->contenu de fournisseur de relation, et depuis c'est le protocole SSL qui supprime un obstacle à l'écriture d'un serveur qui accède à OAuth services.

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

Donc, à ce point de notre serveur dispose d'un droit d'accès permanent jeton qui est un nom d'utilisateur/mot de passe équivalent pour l'utilisateur. Il peut en faire la demande auprès du fournisseur de contenu pour le compte de l'utilisateur en passant que le jeton d'accès dans le cadre de la demande (une requête argument, en-tête HTTP, ou de valider les données du formulaire).

Si le contenu du service est accessible que via SSL, nous avons terminé. Si elle est disponible via HTTP normal, nous tenons à protéger que le jeton d'accès, d'une certaine façon. Quelqu'un renifler la connexion devrait être en mesure d'obtenir l'accès au contenu de l'utilisateur pour toujours.

Le chemin qui est résolu dans OAuth 2 est avec un jeton d'actualisation. L'actualisation jeton devient le mot de passe permanent équivalent, et ne sont transmises via le protocole SSL. Lorsque le serveur a besoin d'accéder au contenu du service, il échange de l'actualisation à un jeton pour une courte durée jeton d'accès. De cette façon, tous les sniffable HTTP accède sont faites avec un jeton qui va expirer. Google est à l'aide d'un 5 minutes à expiration sur leur OAuth 2 Api.

Donc, en plus de l'actualisation des jetons, OAuth 2 simplifie toutes les communications entre le client, le serveur et le fournisseur de contenu. Et l'actualisation des jetons n'existent que pour assurer la sécurité lorsque du contenu est accessible en clair.

Deux pattes d'authentification

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

OAuth 2 standardise les extensions à OAuth 1 qui ont été dans une large utilisation. Celui que je connais le mieux a été introduit par Twitter xAuth. Vous pouvez le voir dans OAuth 2 en tant que Ressource Propriétaire d'un Mot de passe.

Essentiellement, si vous pouvez faire confiance au 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 trois pattes d'authentification, vous devez incorporer un HTTP afficher afin de gérer le processus d'autorisation avec le serveur de contenu.

Avec OAuth 1, ce n'était pas dans la norme officielle, et a exigé la même procédure de signature que toutes les autres demandes.

J'ai juste mis en œuvre le côté serveur OAuth 2 avec des Ressources Propriétaire de Mot de passe, et à partir d'un point de vue du client, obtenir le jeton d'accès est devenu simple: demander un jeton d'accès à partir du serveur, en passant l'id de client/secret HTTP en-tête d'Autorisation et le login de l'utilisateur/mot de passe que les données de formulaire.

Avantage: La Simplicité

Donc, à partir d'un réalisateur de la perspective, les principaux avantages que je vois dans OAuth 2 sont dans la réduction de la complexité. Il ne nécessite pas la demande de procédure de signature, qui n'est pas exactement difficile, mais n'est certainement délicat. Il réduit le travail nécessaire pour agir en tant que client d'un service, qui est là (dans le moderne, mondial de la téléphonie mobile), vous voulez le plus à réduire la douleur. La diminution de la complexité sur le serveur->fournisseur de contenu de fin, il est plus évolutif dans le centre de données.

Et elle codifie dans la norme des extensions à OAuth 1.0 a (comme xAuth) qui sont maintenant en usage.