Clés API vs authentification HTTP vs OAuth dans une API RESTful


101

Je travaille sur la construction d'une API RESTful pour l'une des applications que je gère. Nous cherchons actuellement à y intégrer diverses choses qui nécessitent un accès et une sécurité plus contrôlés. En recherchant comment sécuriser l'API, j'ai trouvé quelques opinions différentes sur le formulaire à utiliser. J'ai vu certaines ressources dire que HTTP-Auth est la voie à suivre, tandis que d'autres préfèrent les clés API, et même d'autres (y compris les questions que j'ai trouvées ici sur SO) ne jurent que par OAuth.

Ensuite, bien sûr, ceux qui préfèrent, par exemple, les clés API, disent que OAuth est conçu pour les applications ayant accès au nom d'un utilisateur (si je comprends bien, comme la connexion à un site non Facebook en utilisant votre compte Facebook), et non pour un utilisateur accédant directement aux ressources d'un site auquel il s'est spécifiquement inscrit (comme le client Twitter officiel accédant aux serveurs Twitter). Cependant, les recommandations pour OAuth semblent être même pour les besoins d'authentification les plus élémentaires.

Ma question, alors, est - en supposant que tout soit fait sur HTTPS, quelles sont certaines des différences pratiques entre les trois? Quand faut-il considérer l'un par rapport aux autres?


avec quoi avez-vous fini par aller?
Irwin

@Irwin - J'ai posé cette question il y a un certain temps et j'ai depuis abandonné le projet qui l'exigeait, mais j'ai fini par utiliser une combinaison de clés API et de mot de passe généré (que les utilisateurs ne voient jamais), qui sont envoyés en utilisant l'authentification HTTP.
Shauna

Réponses:


67

Cela dépend de vos besoins. As-tu besoin:

  • Identité - qui prétend faire une demande d'API?
  • Authentification - sont-ils vraiment ce qu'ils prétendent être?
  • Autorisation - sont-ils autorisés à faire ce qu'ils essaient de faire?

ou les trois?

Si vous avez juste besoin d'identifier l'appelant pour suivre le volume ou le nombre d'appels API, utilisez une simple clé API. Gardez à l'esprit que si l'utilisateur à qui vous avez émis la clé API la partage avec quelqu'un d'autre, il pourra également appeler votre API.

Mais, si vous avez également besoin d'une autorisation, vous devez fournir un accès uniquement à certaines ressources en fonction de l'appelant de l'API, puis utilisez oAuth.

Voici une bonne description: http://www.srimax.com/index.php/do-you-need-api-keys-api-identity-vs-authorization/


avec "certaines ressources" voulez-vous dire "certains appels d'API" ou "certains enregistrements de base de données", ou les deux?
Magne

Principalement des enregistrements de base de données (ou tout ce qui révèle un état protégé ou modifie l'état). Mais cela pourrait aussi être quelque chose comme une fonctionnalité premium (comme exécuter un algorithme sur un cloud) qui ne change vraiment rien sur la base de données, mais utilise des ressources système et ne devrait être disponible que pour les personnes autorisées.
Sid

@Sid Je travaille sur une application qui utilise OAuth pour enregistrer les utilisateurs qui s'inscrivent avec Facebook ou LinkedIn. De plus, nous ouvrons notre API à d'autres services pour gérer les données. Dans ce cas, recommanderiez-vous OAuth pour l'authentification de l'utilisateur, et une clé API ou une combinaison de nom d'utilisateur et de mot de passe (comme dans l'article auquel vous avez lié) pour les services accédant à l'API? OAuth et la clé API sont tous deux utilisés à des fins différentes, non?
Tom Doe

@TomDoe Salut Tom - Oui, cela a du sens. Vous souhaitez probablement utiliser OAuth2 maintenant. Si votre serveur est en Python (Django ou Flask), jetez un œil à github.com/omab/python-social-auth
Sid

Je ne comprends pas comment une clé API ne peut pas fournir ces trois choses. L'identité et l'authentification sont toutes deux basées sur "connaissez-vous un secret particulier?" (sauf si vous introduisez 2FA, qui est un sujet distinct). Si je donne la très longue clé API de l'utilisateur 5, cela prétend et prouve que je suis l'utilisateur 5, au moins aussi bien qu'un nom d'utilisateur / mot de passe. Et il n'y a aucune raison pour que l'on ne puisse pas attribuer des autorisations différentes à différentes clés d'API. Droite? Qu'est-ce que j'oublie ici?
Nathan Long

3

Les clés d'API ou même les jetons entrent dans la catégorie des mécanismes d'authentification et d'autorisation directs, car ils permettent d'accéder aux ressources exposées des API REST. Ces mécanismes directs peuvent être utilisés dans les cas d'utilisation de délégation.

Pour accéder à une ressource ou à un ensemble de ressources exposées par les points de terminaison REST, il est nécessaire de vérifier les privilèges du demandeur en fonction de son identité. La première étape du flux de travail consiste ensuite à vérifier l'identité en authentifiant la demande; une étape successive consiste à vérifier l'identité par rapport à un ensemble de règles définies pour autoriser le niveau d'accès (c'est-à-dire lecture, écriture ou lecture / écriture). Une fois que lesdites étapes sont accomplies, un autre problème typique est le taux de demande autorisé , c'est-à-dire le nombre de demandes par seconde que le demandeur est autorisé à effectuer vers la ou les ressources données.

OAuth (Open Authorization) est un protocole standard pour l' accès délégué , souvent utilisé par les grandes sociétés Internet pour accorder l'accès sans fournir le mot de passe. Comme il est clair, OAuth est un protocole qui répond aux préoccupations mentionnées ci-dessus: authentification et autorisation en fournissant un accès délégué sécurisé aux ressources du serveur au nom du propriétaire de la ressource. Il est basé sur le mécanisme des jetons d'accès qui permettent au tiers d'accéder à la ressource gérée par le serveur pour le compte du propriétaire de la ressource. Par exemple, ServiceX souhaite accéder au compte Google de John Smith au nom de John, une fois que John a autorisé la délégation; ServiceX recevra alors un jeton basé sur le temps pour accéder aux détails du compte Google, très probablement en lecture seule.

Le concept de clé API est très similaire au jeton OAuth décrit ci-dessus. La différence majeure réside dans l'absence de délégation: l'Utilisateur demande directement la Clé au prestataire pour des interactions programmatiques successives. Le cas de la clé API est également basé sur le temps: la clé en tant que jeton OAuth est soumise à un bail de temps ou à une période d'expiration. Comme aspect supplémentaire, la clé ainsi que le jeton peuvent être soumis à une limitation de débit par contrat de service, c'est-à-dire que seul un nombre donné de demandes par seconde peut être servi.

Pour récapituler, il n'y a en réalité aucune différence réelle entre les mécanismes traditionnels d'authentification et d'autorisation et les versions basées sur la clé / jeton. Le paradigme est cependant légèrement différent: au lieu de continuer à réutiliser les informations d'identification à chaque interaction entre le client et le serveur, une clé / jeton de support est utilisée, ce qui rend l'expérience d'interaction globale plus fluide et probablement plus sécurisée (souvent, en suivant la norme JWT , les clés et Les jetons sont signés numériquement par le serveur pour éviter la fabrication).

  • Authentification et autorisation directes : protocoles basés sur des clés en tant que variante des versions traditionnelles basées sur les informations d'identification.
  • Authentification et autorisation déléguées : comme les protocoles basés sur OAuth, qui à leur tour utilisent des jetons, encore une fois comme une variante des versions basées sur les informations d'identification (l'objectif global est de ne pas divulguer le mot de passe à un tiers).

Les deux catégories utilisent un flux de travail de vérification d'identité traditionnel pour la toute première interaction avec le serveur propriétaire de la ou des ressources intéressées.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.