Oauth2 vs APIKey dans une communication de serveur à serveur
Un fournisseur de services tiers expose une API de paiement que nous devons intégrer sur notre backend.
En tant que communication de transport, nous utiliserons cette API à l'aide de TLS avec certificat client et sur un réseau privé MPLS.
Comme cadre d'authentification, le tiers propose Oauth2;
Je propose plutôt une authentification "ligther" comme une APIKey/ClientSecret.
Pourquoi?
Parce que, d'après mon expérience "limitée", je ne vois aucun avantage à utiliser Oauth2 dans ce scénario.
- L'API sera consommé par un seul utilisateur de service utilisé par notre backend.
- Nous n'avons aucun niveau d'autorisation (aucune réclamation).
- Dans Oauth2, pour protéger les informations d'identification, vous les utilisez uniquement pour obtenir un jeton d'accès et vous vous authentifiez auprès de l'API qui l'utilise; dans notre scénario, les informations d'identification ne sont pas des informations d'identification personnelles, mais des informations d'identification de service uniques fournies par le fournisseur d'API tiers. Leur fuite serait comme une fuite d'une APIKey de mon point de vue.
- En cas de violation de la sécurité, il vous suffira de révoquer l'APIKey; avec Oauth2, vous devez révoquer le jeton d'actualisation en laissant le jeton d'accès accordé toujours valide.
- Cela nous obligera à créer une bibliothèque d'utilitaires (basée sur Restsharp) et des tables de base de données pour gérer tous les allers-retours imposés par le protocole Oauth2. Une chose que j'ai vue dans d'autres projets est que cette bibliothèque doit être "synchronisée" en cas d'accès simultané.
Je manque probablement certains points importants et ma simplification excessive n'est pas admise dans un service crucial comme une API de paiement.
D'après votre expérience, Oauth2 présente-t-il certains avantages par rapport à une "authentification de base" dans ce scénario spécifique?
La clé API/secret client a plus de sens pour la communication de service à service, ce qui semble être votre scénario d'après ce que je collecte (votre backend vers leur service API).
Cela dit, OAuth 2 a un flux d'octroi des informations d'identification client , qui peut faire une sorte de clé API/secret client/authentification basée sur le certificat - vérifiez avec votre tierce partie fournisseur pour voir s’ils le soutiennent.
Habituellement OAuth 2 est associé au flux d'autorisation de code d'autorisation , ce qui est bon lorsque l'agent utilisateur est un navigateur car c'est pour cela qu'il a été conçu, mais pas approprié pour service à service.
C'est un sujet intéressant et il y a deux ou trois choses à considérer. Nous devons d'abord y arriver du fournisseur d'API, pas juste du consommateur.
Qui?
La principale considération est l'authentification par rapport à "l'identité" et les autorisations. Rappel:
- Identité = qui dit que vous êtes
- Authentification = qui vous êtes vraiment
- Autorisations = ce que vous pouvez faire
Consultez ce post pour plus de détails sur l'ID API et les autorisations.
Alors que, dans ce cas, les autorisations peuvent être implicites (où, en raison de l'authentification, vous pouvez utiliser l'API), considérez ceci: en tant que fournisseur d'une API pour un service avec le niveau de sensibilité requis, je veux know que le consommateur est qui ils disent être .
La transmission d'une clé API confirme uniquement que vous disposez de la clé API: cela ne prouve pas que vous êtes autorisé à accéder à l'API.
Maintenant, la possession d'un jeton d'accès OAuth peut être initialement la même, mais le OAuth RFC états
Le serveur d'autorisation DOIT authentifier le client autant que possible.
OAuth permet cela en fournissant un jeton d'actualisation, comme vous l'avez dit, ainsi qu'un URI de redirection enregistré. Il suggère également un jeton de portée minimale pour toutes les demandes initiales et de réauthentification.
Cela donne au fournisseur d'API beaucoup plus de contrôle, plus de visibilité et donc plus de confiance que son API n'a pas été compromise.
OAuth joue également bien avec les autorisations. Si la société de passerelle de paiement décidait d'étendre l'authentification pour exiger des autorisations sur GET et sur POST, ce serait moins de travail et plus sécurisé que si vous deviez essayer de lier une clé aux autorisations.
Exposition
Une considération secondaire mais pertinente est de savoir quoi faire si la clé API est exposée.
Je sais que je veux pouvoir faire confiance à la clé, mais elle a peut-être été violée. Donc, je liste également les adresses IP des clients ... Les adresses IP peuvent changer, selon la configuration, et elles peuvent également être usurpées ... Comment puis-je savoir si la clé est utilisée de manière malveillante ou non?
Si la clé API est ensuite réémise après la violation, il peut être plus facile pour quelqu'un de déterminer de nouvelles clés possibles une fois que la clé initiale est connue. Cela signifie que l'algorithme de génération de clé des fournisseurs peut également avoir besoin d'être ajusté.
Si vous avez reçu un jeton d'accès qui a été découvert d'une manière ou d'une autre, une fois qu'il est actualisé, l'utilisateur non autorisé ne devrait pas pouvoir être réautorisé. Je peux les enregistrer, enregistrer cette demande erronée et travailler avec le consommateur pour diagnostiquer la cause première.
Sommaire
La clé API n'a jamais été conçue que pour servir de formulaire d'ID. En tant que tels, ils sont fondamentalement mal utilisés lorsqu'ils sont mis en œuvre en tant que mesure de sécurité principale.
Si les consommateurs d'API doivent être authentifiés - comme vous devez vérifier l'appelant de l'API et fournir un accès à certaines ressources en fonction de cette vérification - OAuth est le meilleur choix.
J'espère que cela t'aides!
[~ # ~] nb [~ # ~] Pour des raisons d'argument, j'ai supposé que personne n'avait un accès root à vos services ou réseaux internes, et tous les communications over-the-wire se font via HTTPS.
Oui, c'est vrai, cela pourrait arriver. Une attaque par rejeu est assez courante mais il existe des moyens de l'implémenter en toute sécurité. Votre serveur doit certainement utiliser la surveillance IP, ce qui signifie qu'une fois le jeton émis, il n'autorisera qu'une adresse IP spécifique, mais cela ne résout pas le problème car le compromis peut être de l'intérieur. La deuxième façon consiste à minimiser le délai d'expiration, ce qui réduit le risque d'exposition. Enfin, il y a toujours des WebSockets ... il se synchronise généralement assez rapidement pour émettre un nouveau jeton par demande, ce qui élimine le plus de risques, car pour son usage professionnel, utilisez-le sur son propre Vlan dédié qui ne peut avoir accès qu'au port x. ... etc
À la fin de la journée, vous pouvez protéger tout ce que vous voulez, vous ne pouvez toujours pas survivre à une attaque MITM, surtout si les certificats racine ont été compromis sur votre machine.