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

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

Les requêtes OAuth1 (plus précisément HMAC) semblent logiques, faciles à comprendre, faciles à développer et vraiment, vraiment sécurisées.

OAuth2, au lieu de cela, apporte des demandes d'autorisation, des jetons d'accès et des jetons d'actualisation, et vous devez faire 3 demandes au tout début d'une session pour obtenir les données que vous recherchez. Et même dans ce cas, l'une de vos demandes finira par échouer à l'expiration du jeton.

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

De plus, comme / r / netsec l'a montré récemment, SSL n'est pas entièrement sécurisé, donc la pression pour tout mettre sur TLS / SSL au lieu d'un HMAC sécurisé me confond.

OAuth soutient qu'il ne s'agit pas de sécurité à 100%, mais de le faire publier et terminer. Cela ne semble pas vraiment prometteur du point de vue d'un fournisseur. Je peux voir ce que le projet essaie de réaliser quand il mentionne les 6 flux différents, mais il ne correspond tout simplement pas dans ma tête.

Je pense qu'il pourrait être plus difficile pour moi de comprendre ses avantages et son raisonnement que de ne pas vraiment l'aimer, donc cela peut être un peu une attaque injustifiée, et désolé si cela peut sembler une diatribe.

Contexte: J'ai écrit des piles de clients et de serveurs pour OAuth 1.0a et 2.0.

OAuth 1.0a et 2.0 prennent en charge l' authentification à deux jambes , où un serveur est assuré de l'identité d'un utilisateur, et l' authentification à trois jambes , où un serveur est assuré 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 en possède également.

Le complexe: l'authentification à trois pattes

Un point principal des spécifications OAuth est qu'un fournisseur de contenu (par exemple Facebook, Twitter, etc.) assure à 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 jambes offre, c'est la possibilité de le faire sans que le client ou le serveur ait 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 d'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 demande souvent son autorisation pour accéder aux ressources.
4. Le fournisseur de contenu redirige le client vers le serveur, l'informant de la réussite 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 pour un jeton d'accès.

Le serveur peut désormais faire des demandes au fournisseur de contenu au nom de l'utilisateur en transmettant le jeton d'accès.

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

Cela se 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 peut 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 se mettent d'accord sur l'ordre des arguments (ils signent donc exactement la même chaîne), et l'une des principales plaintes concernant OAuth 1 est qu'elle nécessite à la fois le serveur et les clients pour trier et signer à l'identique. C'est du code délicat et c'est juste ou vous obtenez 401 Unauthorizedavec 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 tri et la signature des arguments. Le client transmet son secret au serveur, qui le valide directement.

Les mêmes exigences sont présentes dans la connexion serveur-> fournisseur de contenu, 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 aux étapes 1, 2 et 5 ci-dessus.

Donc, à ce stade, notre serveur dispose d'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 transmettant ce jeton d'accès dans le cadre de la demande (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 simple, nous aimerions protéger ce jeton d'accès permanent d'une manière ou d'une autre. Quiconque reniflant la connexion pourrait avoir accès au contenu de l'utilisateur pour toujours.

La façon dont cela est résolu dans OAuth 2 est avec un jeton d'actualisation . Le jeton d'actualisation devient l'équivalent du mot de passe permanent et il n'est transmis que via 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 ses API OAuth 2.

Ainsi, mis à part les 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 non crypté.

Authentification à deux jambes

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

OAuth 2 standardise certaines extensions d'OAuth 1 qui étaient largement utilisées. Celui que je connais le mieux a été présenté par Twitter sous le nom de xAuth . Vous pouvez le voir dans OAuth 2 en tant qu'identifiant de mot de passe du propriétaire de la ressource .

Essentiellement, si vous pouvez faire confiance au client avec les informations d'identification de l'utilisateur (nom d'utilisateur et mot de passe), il peut les é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 incorporer 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.

Je viens d'implémenter 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 client en tant qu'en-tête d'autorisation HTTP et le identifiant / mot de passe de l'utilisateur en tant que données de formulaire.

Avantage: simplicité

Du point de vue d'un implémenteur, les principaux avantages que je vois dans OAuth 2 sont la complexité réduite. Il ne nécessite pas la procédure de signature de la demande, ce qui n'est pas exactement difficile mais certainement délicat. Cela réduit considérablement le travail requis pour agir en tant que client d'un service, c'est là (dans le monde moderne et mobile) que vous souhaitez le plus minimiser la douleur. La complexité réduite du côté 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.0a (comme xAuth) qui sont maintenant largement utilisées.

Tout d'abord, comme clairement indiqué dans l'authentification OAuth

OAuth 2.0 n'est pas un protocole d'authentification.

L'authentification dans le contexte d'un utilisateur accédant à une application indique à une application qui est l'utilisateur actuel et s'il est présent ou non. Un protocole d'authentification complet vous indiquera probablement également un certain nombre d'attributs concernant cet utilisateur, comme un identifiant unique, une adresse e-mail et comment l'appeler lorsque l'application dit "Bonjour".

Cependant, OAuth ne dit rien à l'application. OAuth ne dit absolument rien sur l'utilisateur, ni comment il a prouvé sa présence ou même s'il est toujours là. En ce qui concerne un client OAuth, il a demandé un jeton, a obtenu un jeton et a finalement utilisé ce jeton pour accéder à une API. Il ne sait rien qui a autorisé l'application ou s'il y avait même un utilisateur.

Il existe une norme pour l'authentification des utilisateurs à l'aide d'OAuth: OpenID Connect, compatible avec OAuth2.

Le jeton ID OpenID Connect est un jeton Web JSON (JWT) signé qui est donné à l'application cliente à côté du jeton d'accès OAuth normal. Le jeton d'identification contient un ensemble de revendications concernant la session d'authentification, y compris un identifiant pour l'utilisateur (sous), l'identifiant pour le fournisseur d'identité qui a émis le jeton (iss) et l'identifiant du client pour lequel ce jeton a été créé ( aud).

Dans Go, vous pouvez consulter coreos / dex, un fournisseur d'identités OpenID Connect (OIDC) et OAuth 2.0 avec connecteur enfichable.

Réponse de ce post vonc

Je répondrais à cette question un peu différemment, et je serai très précis et bref, principalement parce que @Peter T a répondu à toutes.

Le principal gain que je constate de cette norme est de respecter deux principes:

1. Séparation des préoccupations.
2. Découplage de l'authentification de l'application Web, qui sert généralement les entreprises.

En faisant cela,

1. Vous pouvez implémenter une alternative à Single SignOn: si vous avez plusieurs applications qui approuvent un STS. Ce que je veux dire, un nom d'utilisateur pour toutes les applications.
2. Vous pouvez activer votre application Web (le client) pour accéder aux ressources qui appartiennent à l'utilisateur et n'appartiennent pas à l'application Web (le client).
3. Vous pouvez confier le processus d'authentification à un tiers de confiance et ne vous souciez jamais de la validation de l'authenticité de l'utilisateur.