Comment configurer et utiliser l'authentification OAuth à l'aide de l'API WP REST
Publié: 2016-11-30
En ce qui concerne l'API REST WordPress, OAuth est le fournisseur de gestion d'authentification le plus courant.
Lorsque l'authentification OAuth est en place, les utilisateurs se connectent d'abord via le formulaire de connexion WordPress utilisé sur le site Web. cependant, cette connexion autorise également les clients à traiter les demandes en leur nom et toutes les demandes ultérieures sont validées via des jetons OAuth. Ces jetons sont également utilisés pour gérer toutes les demandes d'accès aux API. Cet accès peut être révoqué à tout moment.
L'utilisation la plus importante du processus d'authentification OAuth est peut-être le processus sécurisé de traitement des demandes d'API REST sans exposer les informations d'identification des utilisateurs. Ceci est particulièrement important dans le cas des serveurs de production où les informations d'identification sont souvent échangées. Dans de tels scénarios, l'authentification OAuth est utilisée pour fournir une procédure sûre pour le traitement des demandes fréquentes d'identifiants de connexion.
- Authentification traditionnelle versus OAuth
- Flux de travail d'authentification OAuth
- Installation de l'authentification OAuth
- Évaluation de la disponibilité de l'API OAuth
- Création et gestion d'applications
- CLI client pour générer des informations d'identification OAuth
- Client HTTP pour générer des informations d'identification OAuth
- Acquérir des informations d'identification temporaires
- Autorisation de l'utilisateur
- Échange de jetons
- Envoi d'une demande authentifiée de test
Authentification traditionnelle versus OAuth
Afin de comprendre la signification de l'authentification OAuth, il est important de comprendre le modèle d'authentification traditionnel et OAuth.
Dans le modèle d'authentification traditionnel, il existe deux entités clés ; Client et fournisseur de ressources/services. Le client peut être une application Web, un service ou un utilisateur, tandis que le fournisseur de ressources/services dispose des ressources ou services souhaités dans un environnement à accès restreint.
Lorsque le Client a besoin d'une ressource particulière, il s'authentifie auprès du Fournisseur de ressources en fournissant les informations d'identification appropriées. Bien qu'il s'agisse d'un processus simple, il existe également un risque énorme de violation de la sécurité.
En revanche, le modèle d'authentification OAuth est légèrement plus complexe avec trois entités ; Client qui agit au nom de l'utilisateur, Utilisateur qui a besoin d'accéder à une ressource et Serveur qui gère la ressource.
Puisqu'il y a trois entités, le processus est connu sous le nom d'authentification à trois étapes. Cependant, dans les cas où le Client et l'Utilisateur sont les mêmes entités, le processus d'authentification devient une authentification à deux volets.
Flux de travail d'authentification OAuth

- Le Client demande à l' Utilisateur l' autorisation d'accéder au Serveur .
- Si l' utilisateur accepte la demande, le client reçoit le droit de poursuivre.
- Le Client présente son identité et le mandat du Client au Serveur d'Autorisation (API) et demande un jeton.
- En cas de validation réussie de l'identité et du mandat, le Serveur d'Autorisation (API) délivre un jeton d'accès au Client . À ce stade, l'authentification est terminée.
- Ensuite, le Client s'approche du Serveur pour demander une ressource particulière. A ce stade, le Client envoie également le jeton d'accès au
- Si le jeton d'accès est validé, le Serveur accorde l'accès à la ressource demandée.
Le client est à l'origine de la demande signée d'un jeton de demande. Cette demande est également connue sous le nom d'informations d'identification temporaires. La demande est envoyée à l'URI du point de terminaison approprié. Cette requête comprend plusieurs paramètres importants :
- oauth_consumer_key : Cette clé identifie l'application à l'origine de la requête.
- oauth_timestamp : Les serveurs utilisent cet horodatage pour l'optimisation du stockage des nonces.
- oauth_nonce : il s'agit du jeton unique généré par l'application pour chaque demande individuelle.
- oauth_signature : cette partie importante de la requête API est le hachage de tous les composants de la requête et de certaines valeurs OAuth.
- oauth_signature_method : Le plugin OAuth propose une méthode de signature unique : HMAC-SHA1.
- oath_callback : L'URL vers laquelle l'utilisateur est redirigé après autorisation. La demande est vérifiée et un jeton de demande avec les paramètres suivants est émis.
- oauth_token : il s'agit du jeton d'application qui est supprimé de la réponse du serveur d'autorisation. Ce jeton est ensuite envoyé au serveur API.
- oauth_token_secret : Ceci est similaire au mot de passe utilisateur. La demande est alors autorisée par le Client. Pour cela, un URI de demande est créé et oauth_token est ajouté à l'URI du point de terminaison d'autorisation du serveur. L'Utilisateur autorise l'envoi de cette demande en fournissant les informations d'identification appropriées.
Dans le cas où l' URI oauth_callback est disponible dans la première étape, le serveur redirige vers l'URI avec les paramètres suivants ajoutés à la chaîne de requête :
- oauth_token : avoir déjà le jeton.
- oauth_verifier : vérifie l'identité du propriétaire de la ressource auprès du client.
Si l'URI oauth_callback n'a pas été fourni lors de la première étape, le serveur envoie la valeur de oauth_verifier afin que le propriétaire de la ressource puisse informer le client manuellement.
Après avoir reçu oauth_verfier , le client demande au serveur les informations d'identification du jeton. Cela prend la forme d'une demande à l'URI du point de terminaison de demande de jeton. Cette requête contient les paramètres suivants :
- oauth_token
- oauth_verfier
- oauth_consumer_key
- oauth_signature
- oauth_signature_method
- oauth_nonce
- oauth_version
Installation de l'authentification OAuth
Dans le contexte de WordPress, l'authentification OAuth est implémentée en installant l'API d'authentification OAuth pour WordPress. Ceci est basé sur les spécifications OAuth 1.0a et étend en fait ces spécifications par un paramètre supplémentaire wp_scope. Ce paramètre est envoyé au point de terminaison de demande d'informations d'identification temporaire .
Le plugin est disponible sur Github auprès de l'équipe WP REST API. Pour le moment, les versions 4.4 et ultérieures sont prises en charge.
Je vais commencer le processus de clonage du plugin en me déplaçant dans le répertoire /wp-content/plugins/ :
git clone https://github.com/WP-API/OAuth1.git

Une fois le téléchargement terminé, activez le plugin via WordPress CLI :
plugin wp activer OAuth1
Si vous ne souhaitez pas utiliser WordPress CLI, vous pouvez accéder à WordPress Admin >> Plugins et activer le plugin à partir du menu. Alternativement, vous pouvez également l'activer en naviguant dans votre navigateur jusqu'à votre section de plugins d'administration WordPress si vous ne souhaitez pas utiliser WP CLI.
Évaluation de la disponibilité de l'API OAuth
Avant d'initier la négociation OAuth, je vais d'abord vérifier si l'API est activée sur le serveur. Cela se fait en envoyant une simple requête GET au /wp-json/ endpoint puis en analysant la réponse envoyée par le serveur.
OBTENIR http://Server-Dev/wp-json/
Cela renverra une réponse JSON comme suit :

Mon objectif ici est la valeur oauth1 dans la valeur de la propriété d' authentification . Cet objet a les propriétés suivantes définies :
- request : le point de terminaison de demande d'informations d'identification temporaire
- autoriser : le point de terminaison d'autorisation du propriétaire de la ressource
- accès : le point de terminaison de demande de jeton
- version : la version d'OAuth utilisée
Si l'API OAuth n'est pas activée pour un site, la réponse du serveur contiendrait une valeur de propriété d' autorisation vide.

Création et gestion d'applications
La première étape consiste à s'assurer que le plugin OAuth1.0 est installé et activé correctement.

Ensuite, je peux créer et gérer des applications en allant dans WordPress Admin >> Users >> Applications.

Sur cette page Applications enregistrées , j'enregistrerai une nouvelle application en cliquant sur le bouton Ajouter une nouvelle , puis en remplissant les trois champs suivants :
- Nom du client : Le nom du client qui apparaît dans la section Applications autorisées et pendant le processus d'autorisation.
- Description : La description facultative du Client.
- URL de rappel : L'URL de rappel est utilisée lors de la génération d'informations d'identification temporaires.
Une fois créés en cliquant sur le bouton Enregistrer le client , les paramètres Clé client et Secret client apparaîtront au bas de la page pour ce client particulier.

Je vais maintenant cloner le référentiel sur le client en exécutant la commande suivante :
git clone https://github.com/WP-API/client-cli

Naviguez maintenant dans le répertoire cloné et installez les dépendances du package à l'aide de Composer :
cd client-cli installer le compositeur
Si tout se passe bien, la ligne de commande devrait afficher quelque chose de similaire à ce qui suit :

CLI client pour générer des informations d'identification OAuth
Pour démarrer le processus d'autorisation OAuth, je vais d'abord obtenir les paramètres suivants du serveur :
- oauth_consumer_key
- oauth_consumer_secret
Cela sera généré via le terminal et en exécutant la commande WordPress CLI suivante :
wp oauth1 ajouter
La clé et le secret sont le oauth_consumer_key et oauth_consumer_secret respectivement.
Maintenant, je dois lier le client au site WordPress. Sur le client, accédez au répertoire client-cli (cloné précédemment) et exécutez la commande suivante :
wp --require=client.php api oauth1 connect http://Server-Dev/ --key=<votre clé ici> --secret=<votre secret ici>
Remplacez l'URL, la clé et le secret dans la commande ci-dessus. La sortie devrait ressembler à la suivante :
wp --require=client.php api oauth1 connect http://votre-serveur/wordpress-api/ --key=<votre clé> --secret=<votre code secret> Ouvrez dans votre navigateur : http://your-server/wordpress-api/oauth1/authorize?oauth_token=<your-token> Entrer le code de vérification:
Accédez à l'URL fournie par le serveur et authentifiez-vous en cliquant sur le bouton Autoriser :

Le jeton de vérification (ou oauth_verifier) vous sera présenté sur l'écran suivant :

Copiez le vérificateur et collez-le dans le terminal. Vous recevrez une clé et un secret , qui sont respectivement oauth_token et oauth_token_secret :
Client HTTP pour générer des informations d'identification OAuth
Étant donné que le plug-in de serveur OAuth 1.0a suit le flux standard en trois étapes, la génération d'informations d'identification OAuth implique les étapes suivantes :
- Acquisition d'identifiants temporaires
- Autorisations des utilisateurs
- Échange de jetons
Acquérir des informations d'identification temporaires
J'enverrai une requête POST au point de terminaison /oauth1/request pour obtenir les informations d'identification temporaires. Notez que ce point de terminaison doit être détectable automatiquement car un serveur peut remplacer la route par lui-même.
La requête POST doit inclure les paramètres et oauth_consumer_secret tels qu'ils ont été acquis lors de l'enregistrement d'un consommateur pour l'application. La demande peut également inclure le paramètre oauth_callback et cette URL de rappel doit correspondre au schéma, à l'hôte, au port et au chemin de l'URL de rappel qui a été fourni lors de l'enregistrement de l'application.
En plus des paramètres oauth_consumer_key et oauth_consumer_secret , la demande doit également inclure les paramètres oauth_signature et oauth_signature_method .
Lors de l'utilisation de Postman, la signature oauth_signature est générée automatiquement. Je n'ai qu'à mentionner le paramètre oauth_signature_method . Pour le moment, seule la méthode de signature HMAC-SHA1 est prise en charge par le plugin du serveur OAuth.
Je vais maintenant configurer Postman pour envoyer une requête POST au point de terminaison des informations d'identification du jeton temporaire. Ensuite, dans l'onglet Autorisation , sélectionnez l'option OAuth 1.0 dans la liste déroulante. Remplissez les champs Consumer Key et Consumer Secret avec les valeurs fournies par le consommateur. Enfin, vérifiez que l'option Méthode de signature est définie sur HMAC-SHA1 .
Autorisation de l'utilisateur
Pour l'étape d'autorisation de l'utilisateur, je vais ouvrir le point de terminaison d'autorisation du propriétaire de la ressource dans le navigateur et transmettre le oauth_token et oauth_token_secret tel qu'obtenu à l'étape précédente en tant que paramètres de requête :
http://server-dev/oauth1/authorize?oauth_token=<token_here>&oauth_token_secret=<secret_here>

Autorisez l'application en cliquant sur le bouton Autoriser . L'écran suivant présentera un jeton de vérification. Ce jeton agira désormais comme un jeton oauth_verifier à l'étape suivante.
Une fois que l'utilisateur a autorisé le client, l'application apparaîtra sous la section Applications autorisées sur la page Utilisateurs > Votre profil .
Échange de jetons
En utilisant à nouveau l'option OAuth 1.0 dans l'onglet Autorisation , remplissez les champs pour la clé du consommateur et le secret du consommateur avec les valeurs fournies par le consommateur. Dans les champs Token et Token Secret, insérez la valeur des paramètres oauth_token et oauth_token_secret (informations d'identification temporaires).
Comme je peux également passer des paramètres dans l'URL en tant que paramètres de requête, ajoutez le paramètre oauth_verifier à l'URL comme suit :
http://server-dev/oauth1/access?oauth_verifier=<oauth_verifier_value>
Avec tous les paramètres en place, envoyez la demande en cliquant sur le bouton Envoyer . Si tout se passe bien, le serveur renverra un code d'état 200 - OK avec le corps de la réponse contenant les paramètres oauth_token et o auth_token_secret .
oauth_token=<oauth_token_value>&oauth_token_secret=<oauth_secret_value>
À ce stade, les jetons temporaires acquis précédemment sont défaussés et ne peuvent plus être utilisés.
Les nouveaux paramètres oauth_token et oauth_token_secret sont les informations d'identification OAuth que vous pouvez utiliser dans le client pour générer des demandes authentifiées.
Envoi d'une demande authentifiée de test
Maintenant que j'ai les informations d'identification du jeton, j'enverrai une demande de test au serveur à l'aide de Postman. La demande nécessitera les paramètres suivants :
Vous aurez besoin des éléments suivants avant de commencer :
- oauth_consumer_key
- oauth_consumer_secret
- oauth_token
- oauth_token_secret
Sélectionnez OAuth 1.0 dans la liste déroulante sous l'onglet Autorisation dans Postman.

Une fois que vous avez rempli tous les champs, cliquez sur le bouton Mettre à jour la demande . Cochez l'option Ajouter des paramètres à l'en-tête pour envoyer les paramètres dans l'en-tête de la demande au lieu de les ajouter à la chaîne de requête.
Si la demande aboutit, le serveur enverra un code d'état 200 - OK .
Emballer!
Dans ce didacticiel, j'ai expliqué comment configurer l'API d'authentification OAuth pour WordPress sur un serveur et comment utiliser le client HTTP pour obtenir les informations d'identification du jeton. Si vous découvrez un problème dans le code ou souhaitez ajouter à la discussion, veuillez laisser un commentaire ci-dessous.
