Sécuriser mon API REST avec OAuth tout en autorisant l’authentification via des fournisseurs OAuth tiers (en utilisant DotNetOpenAuth)

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

Récemment, divers tiers se sont intéressés à l’intégration de leurs clients de bureau avec l’API pour permettre aux utilisateurs de mon produit d’accéder à leurs données en utilisant cette application tierce.

J’ai vu que les applications souhaitant utiliser Twitter s’authentifient à l’aide d’une page de connexion hébergée sur Twitter qui accorde à une application spécifique l’autorisation 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 approfondies, 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 documentés (voire pas du tout) et les seuls didacticiels que je peux trouver en ligne semblent être axés sur la fourniture d’un mécanisme de connexion à vos utilisateurs afin qu’ils puissent se connecter à votre site Web avec un fournisseur tiers.

Ce que je voudrais vraiment faire, c’est que mon API REST gère toute l’authentification de base et la logique métier de mon application Web et que mon application web soit essentiellement une autre application qui utilise l’API via OAuth. Les utilisateurs s’authentifieraient sur le site Web soit directement en utilisant leur nom d’utilisateur et mot de passe, soit via un fournisseur tiers tel que MyOpenID ou Facebook, puis le site Web utiliserait le jeton retourné pour s’authentifier auprès de l’API REST.

Schéma architectural

Il semble fondamentalement que j’ai besoin de mon API pour héberger en quelque sorte un service OAuth, mais que les utilisateurs utilisent également un service OAuth tiers. Je ne peux pas m’empêcher de penser que je ne sais pas assez sur OAuth pour décider si je suis trop compliqué 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 me donner au moins un aperçu général des étapes que je dois entreprendre ou de ce que je devrais envisager pour y parvenir? Ou me diriger vers des tutoriels? Ou faire sauter ma proposition et me dire que je vais à ce sujet (sur le plan architectural) tout est faux?

Tout d’abord, je voudrais souligner la différence entre l’authentification et l’autorisation:

Un utilisateur s’authentifie sur votre site Web en fournissant des informations d’identification telles qu’un nom d’utilisateur et un mot de passe. OpenID permet à l’utilisateur de s’authentifier auprès d’un autre service, qui revendique ensuite l’identité de l’utilisateur sur votre site Web. Votre site approuve le service tiers (le fournisseur OpenID) et considère donc l’utilisateur connecté.

Un service ou une application ne s’authentifie pas sur votre site Web, du moins pas en général. Un utilisateur autorise un service ou une application à accéder aux données de l’utilisateur. Cela 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 (le fournisseur de services sait donc à qui il s’adresse) et l’utilisateur dit au site “oui, il est acceptable 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 utilisateur sur le site du fournisseur de services. Notez que l’application ne s’authentifie pas comme si elle était l’utilisateur, mais utilise un autre code pour garantir que le service est autorisé à accéder aux données d’un utilisateur particulier.

Ainsi, avec cette distinction clarifiée, vous pouvez prendre des décisions sur votre site en matière d’authentification et d’autorisation de manière totalement indépendante. 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. Une décision complètement orthogonale est la manière dont vous autorisez les applications (il existe de nombreux protocoles que vous pouvez utiliser pour cela, bien sûr, OAuth étant très populaire).

OpenID est axé sur l’ authentification de l’ utilisateur. OAuth se concentre sur l’ autorisation des applications. 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 fortement de consulter le modèle de projet de site Web ASP.NET MVC 2 OpenID (C #) disponible à partir de la galerie VS. Il est livré avec l’authentification OpenID et la prise en charge de OAuth Service Provider. Cela signifie que vos utilisateurs peuvent se connecter avec OpenID et que les applications et services tiers peuvent utiliser OAuth pour effectuer des appels API sur votre site Web et accéder aux données utilisateur.

Ce que vous voulez append à 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 les implémenter car ils n’utilisent pas le standard OpenID. Mais le téléchargement de DotNetOpenAuth inclut des exemples pour vous connecter avec Twitter et Facebook, vous avez donc des conseils à ce sujet.

Je soupçonne que vous n’aurez pas grand chose à faire sur le front de l’autorisation. Cela vient avec OAuth comme je l’ai déjà dit, et cela vous suffira probablement.

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

Votre API est essentiellement des ressources et des méthodes pour manipuler ces ressources. Et vous pouvez avoir plusieurs méthodes d’authentification de l’access à votre API.

OAuth est l’un de ces mécanismes d’authentification. Être un fournisseur OAuth est génial, même si la spécification est un peu difficile à comprendre, en particulier les parties liées aux signatures. Une fois que vous avez OAuth en place, les applications clientes ont généralement la possibilité de s’authentifier facilement, car il existe tellement de bibliothèques “open source, déjà réalisées, juste implémentées”, disponibles dans la plupart des langues.

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

Pour moi, les seules alternatives réelles à OAuth sont OAuth 2.0 et une simple authentification de base.

En dehors de cela, vous parlez d’authentifier en utilisant Open-ID, ou l’identité Facebook, etc. C’est encore une autre question que vous devez vous poser. Mais cela dépasse vraiment le cadre des API et de OAuth. Pour moi, cela fait davantage penser à la création d’utilisateurs dans votre service. J’ai peut-être tort.