Clés d'API vs authentification HTTP vs OAuth dans une API RESTful
Je travaille à la création 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 la forme à 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, disons, les clés API, disent que OAuth est conçu pour les applications obtenant l'accès au nom d'un utilisateur (si je comprends bien, comme la connexion à un non -Facebook 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 semble être même pour les besoins d'authentification les plus élémentaires.
Ma question est donc la suivante: en supposant que tout se fasse via HTTPS, quelles sont les différences pratiques entre les trois? Quand faut-il considérer l'un par rapport aux autres?
Cela dépend de vos besoins. As-tu besoin:
- Identité - qui prétend faire une demande d'API?
- Authentification - sont-ils vraiment qui ils disent ê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 auquel 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 uniquement fournir un accès à 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/
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 accordent l'accès aux ressources exposées des API REST. Ces mécanismes directs peuvent être utilisés dans des cas d'utilisation de délégation.
Afin d'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é par authentification la demande; l'é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 lire, écrire ou lire/écrire). Une fois lesdites étapes accomplies, une autre préoccupation typique est le taux de requêtes autorisé, c'est-à-dire le nombre de requêtes par seconde que le demandeur est autorisé à effectuer vers la ou les ressources données.
OAuth (Open Authorization) est un protocole standard pour accès délégué, souvent utilisé par les principales 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 un mécanisme de jetons d'accès qui permet de le tiers pour accéder à la ressource gérée par le serveur au nom 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 sera alors émis une fois Token pour accéder aux détails du compte Google, très probablement en accès en lecture uniquement.
Le concept de clé API est très similaire à OAuth Token décrit ci-dessus. La principale différence réside dans l'absence de délégation: l'utilisateur demande directement la clé au fournisseur de services pour des interactions programmatiques successives. Le cas de la clé API est également basée sur le temps: la clé et le jeton OAuth sont soumis à un bail de durée ou à une période d'expiration. Comme aspect supplémentaire, la clé ainsi que le jeton peuvent être soumis à limitation de débit par contrat de service, c'est-à-dire que seul un nombre donné de demandes par seconde peut être traité.
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 les clés/jetons. 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é/un jeton de support est utilisé, ce qui rend l'expérience d'interaction globale plus fluide et probablement plus sécurisée ( souvent, suivant la norme JWT , les clés et les jetons sont signés numériquement par le serveur pour éviter la création).
- Authentification et autorisation directes : protocoles basés sur les clés comme une 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 n'est pas de divulguer le mot de passe à un tiers).
Les deux catégories utilisent un workflow de vérification d'identité traditionnel pour la toute première interaction avec le serveur propriétaire des ressources intéressées.