web-dev-qa-db-fra.com

Sécurisation de mon REST avec OAuth tout en permettant l'authentification via une tierce partie OAuth (en utilisant DotNetOpenAuth)

J'ai un produit avec une API simple REST) afin que les utilisateurs du produit puissent s'intégrer directement aux fonctionnalités du produit sans utiliser l'interface utilisateur Web.

Récemment, divers tiers ont manifesté de l'intérêt pour l'intégration de leurs clients de bureau à l'API afin de permettre aux utilisateurs de mon produit d'accéder à leurs données à l'aide de cette application tierce.

J'ai vu que les applications qui souhaitent utiliser Twitter s'authentifient à l'aide d'une page de connexion hébergée par Twitter qui accorde à une application la permission d'accéder aux données de cet utilisateur. Vous cliquez sur le bouton "Autoriser" ou "Refuser" et le processus d'authentification est terminé. Facebook utilise le même mécanisme que je peux dire.

Après des recherches plus poussées, cela semble être OAuth en action et, vu que mon API est basée sur .Net, je pense que je devrais utiliser DotNetOpenAuth et fournir un mécanisme similaire. Malheureusement, les échantillons sont peu nombreux. documentés (le cas échéant) et les seuls didacticiels que je puisse trouver en ligne semblent viser principalement à vous aider à fournir un mécanisme de connexion à vos utilisateurs afin qu'ils puissent se connecter à votre site Web à l'aide d'un fournisseur tiers.

Ce que je voudrais réellement , c’est que mon API REST gère l’ensemble de la logique d’authentification et commerciale de mon application Web et sous le capot, mon application Web est essentiellement une autre application qui utilise simplement l'API via OAuth. Les utilisateurs s'authentifieraient sur le site Web directement à l'aide de leur nom d'utilisateur et de leur mot de passe, ou via un fournisseur tiers, tel que MyOpenID ou Facebook. le site Web utiliserait alors le jeton renvoyé pour s'authentifier auprès de l'API REST.

Architectural Diagram

Il semble en gros que j’ai besoin de mon API pour héberger un service OAuth, mais aussi que les utilisateurs utilisent un tiers OAuth. Je ne peux pas vous aider mais pense que je n'ai pas assez de connaissances sur OAuth pour décider si je complique trop les choses ou si ce que j'essaie de faire est une bonne ou une mauvaise façon de faire les choses.

Est-ce que quelqu'un peut au moins me donner un aperçu général des démarches que je dois entreprendre ou de ce que je devrais regarder pour que cela se produise? Ou me diriger vers des tutoriels? Ou exploser ma proposition et me dire que je me trompe (architecturalement)?

138
Nathan Ridley

J'aimerais tout d'abord souligner la différence entre authentification et autorisation:

Un utilisateur s'authentifie sur votre site Web en fournissant des informations d'identification, telles qu'un nom d'utilisateur + un mot de passe. OpenID autorise le déplacement de celui-ci si l'utilisateur authenticate est affecté à un autre service, qui assigne ensuite l'identité de l'utilisateur sur votre site Web pour le compte de l'utilisateur. Votre site fait confiance au service tiers (le fournisseur OpenID) et considère donc que l'utilisateur est connecté.

Un service ou application ne s'authentifie pas sur votre site Web - du moins pas typiquement. Un utilisateur autorise un service ou une application pour accéder aux données de l'utilisateur. Ceci est généralement effectué par l'application qui demande l'autorisation du fournisseur de services, puis envoie l'utilisateur au fournisseur de services, où l'utilisateur s'authentifie d'abord (pour que le fournisseur de services sache à qui il parle), puis l'utilisateur dit au site "oui, il est normal que [application] accède à mes données [de manière restreinte] ". À partir de ce moment, l’application utilise un jeton d’autorisation pour accéder aux données de l’utilisateur sur le site du fournisseur de service. Notez que l'application ne s'authentifie pas comme s'il s'agissait de l'utilisateur, mais utilise un autre code pour assurer le service qu'elle est autorisée à accéder aux données d'un utilisateur particulier.

Donc, avec cette distinction clarifiée, vous pouvez prendre des décisions sur l'authentification et l'autorisation sur votre site en toute indépendance. Par exemple, si vous souhaitez que vos utilisateurs puissent se connecter avec tous les éléments suivants: nom d'utilisateur + mot de passe, OpenID et Facebook, vous pouvez le faire. La manière dont vous autorisez les applications est une décision complètement orthogonale (il existe de nombreux protocoles que vous pouvez utiliser à cet effet, OAuth étant bien sûr très populaire).

OpenID est axé sur l'utilisateur authentication. OAuth est centré sur l'application autorisation. Cependant, quelques services tels que Facebook et Twitter ont choisi d'utiliser OAuth pour l'authentification et l'autorisation au lieu d'utiliser OpenID pour l'authentification et OAuth pour l'autorisation. .

Maintenant, pour votre propre projet, je vous recommande vivement de consulter le modèle de projet site Web ASP.NET MVC 2 OpenID (C #) disponible dans la galerie VS. Il est livré avec l'authentification OpenID et OAuth Prise en charge du fournisseur de services. Cela signifie que vos utilisateurs peuvent se connecter avec OpenID et que les applications et services tiers peuvent utiliser OAuth pour passer des appels d'API sur votre site Web et accéder aux données de l'utilisateur.

Il semble que vous souhaitiez ajouter à ce modèle de projet une fois que vous avez commencé, c'est la possibilité pour vos utilisateurs de se connecter avec un nom d'utilisateur + un mot de passe, ainsi qu'avec OpenID. De plus, si vous souhaitez que Facebook et Twitter soient une option pour vos utilisateurs, vous devez également l'implémenter, car ils n'utilisent pas le standard OpenID. Toutefois, le téléchargement DotNetOpenAuth inclut des exemples de connexion à Twitter et Facebook afin que vous puissiez vous y guider.

Je soupçonne que vous n’auriez pas grand-chose à faire s’il ya quelque chose à faire en ce qui concerne les autorisations. Il vient avec OAuth comme je l'ai dit auparavant, et cela vous suffira probablement.

123
Andrew Arnott

Tout d'abord. Vous devez séparer mentalement quelle est votre API - des méthodes d'authentification.

Votre API est essentiellement constituée de ressources et de méthodes permettant de manipuler ces ressources. Et vous pouvez avoir plusieurs méthodes pour authentifier l'accès à votre API.

OAuth est l'un de ces mécanismes d'authentification. Être un fournisseur OAuth est excellent, même si la spécification est un peu difficile à comprendre, en particulier les parties relatives aux signatures. Une fois que vous avez OAuth à la place, les applications clientes ont généralement du mal à s’authentifier, car il y a tant de bibliothèques "open source, déjà faites, il suffit de mettre en oeuvre" des bibliothèques disponibles dans la plupart des langues.

Les avantages et les inconvénients de OAuth ont été débattus pendant un certain temps. Mais pour vous faire votre propre opinion, je suggère de lire ce guide définitif, écrit par Eran Hammer-Lahav , un des personnes responsables de la spécification OAuth.

Les seules vraies alternatives à OAuth autant que je sache, sont OAuth 2.0 et à une simple authentification de base.

En dehors de cela, vous parlez d'authentification en utilisant Open-ID, ou identité Facebook, etc. C'est encore une autre question que vous devez vous poser. Mais cela sort vraiment du cadre des API et de OAuth. Pour moi, il s’agit plus d’une question de création d’utilisateur dans votre service. J'ai peut-être tort.

11
Jon Nylander