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.