Share
Dans la partie précédente de la série, nous avons configuré l'authentification HTTP de base sur le serveur en installant le plug-in disponible sur GitHub par l'équipe API WP REST. La méthode d'authentification de base nous permet d'envoyer des demandes authentifiées en envoyant des informations de connexion dans l'en-tête de la demande. Bien que rapide et pratique, il est également possible que ces informations d'identification tombent entre de mauvaises mains. Par conséquent, cette méthode ne devrait être utilisée que sur des réseaux sécurisés à des fins de développement et de test..
Pour utiliser l'authentification sur des serveurs de production, il est nécessaire de disposer d'un moyen plus sûr d'envoyer des demandes authentifiées sans risquer d'exposer les informations d'identification de connexion. Grâce à la méthode d'authentification OAuth, ces demandes peuvent être envoyées sans exposer le nom d'utilisateur et le mot de passe de manière non sécurisée..
Dans la partie actuelle de la série, nous allons apprendre à configurer et utiliser la méthode d'authentification OAuth à utiliser avec le plug-in WP REST API. Pour être précis, nous allons:
Commençons par nous présenter à la méthode d'authentification OAuth.
Que faites-vous lorsque vous devez vous connecter à votre administrateur WordPress? Vous allez simplement à la page de connexion et entrez vos identifiants de connexion, non? C'est simple! Mais que se passe-t-il si vous utilisez un service tiers nécessitant un accès à vos ressources WordPress (publications, pages, média, etc.)? Souhaitez-vous simplement remettre vos identifiants de connexion à ce service, sachant qu'ils risquent de tomber entre de mauvaises mains chaque fois que l'intégrité de ce service est compromise? La réponse serait probablement "non".
Dans le modèle traditionnel d'authentification, il existe deux rôles:
Si un client souhaite accéder à des ressources protégées, il s'authentifiera en fournissant les informations d'identification appropriées au serveur et obtiendra l'accès..
Le problème se pose lorsqu'un service tiers a besoin d'accéder à ces ressources protégées sur le serveur. Ce service ne peut pas être (et devrait ne pas être) donné des informations d'identification par l'utilisateur pour accéder aux ressources. Fournir des informations d'identification à un tiers signifie donner un contrôle complet sur la ressource située sur le serveur..
C'est là que la méthodologie d'authentification OAuth vient à la rescousse. Il introduit un nouveau rôle dans le processus d’authentification, et c’est le propriétaire de la ressource. Il existe maintenant trois rôles dans le processus d'authentification:
Les trois rôles ci-dessus forment ensemble ce que l'on appelle une authentification OAuth à trois pieds. Le nombre de branches définit les rôles impliqués dans un processus d'authentification. Lorsque le propriétaire de la ressource est également le client, le flux devient une authentification à deux branches..
Selon Webopedia:
OAuth est une norme d'autorisation ouverte utilisée pour fournir un accès d'application client sécurisé aux ressources du serveur. La structure d'autorisation OAuth permet à une application tierce d'obtenir un accès limité à un service HTTP, soit pour le compte d'un propriétaire de ressource, soit en permettant à l'application tierce d'obtenir un accès pour son propre compte..
OAuth permet aux propriétaires de serveur d'autoriser l'accès aux ressources du serveur sans partager les informations d'identification. Cela signifie que l'utilisateur peut accorder l'accès à des ressources privées d'un serveur à un autre sans devoir partager son identité..
Ainsi, dans le flux d'authentification OAuth, l'utilisateur n'a pas besoin de révéler ses informations d'identification, mais peut autoriser le client à agir en son nom, en décidant des ressources auxquelles le client peut accéder. En d'autres termes, tout en ne donnant pas les informations d'identification de connexion, l'utilisateur peut également décider de l'étendue de l'accès accordé au client..
Cela permet non seulement aux sites Web mais également aux applications de bureau et mobiles d'obtenir un accès limité à une ressource sur un serveur..
En termes de WordPress, OAuth informe le fournisseur de ressources (l'installation de WordPress) que le propriétaire de la ressource (l'utilisateur WordPress) a donné l'autorisation d'accéder à une application tierce pour accéder à ses ressources. Ces ressources peuvent être des publications, des pages, une taxonomie, des médias, etc. Cette autorisation peut être pour un accès limité ou complet, comme nous le verrons plus loin dans ce tutoriel..
L'API d'authentification OAuth pour WordPress repose sur les spécifications OAuth 1.0a. Par conséquent, nous allons examiner comment fonctionne OAuth 1.0a..
OAuth fonctionne en utilisant les informations d'identification du jeton qui sont émises par le fournisseur de ressources (le serveur), à la demande du propriétaire de la ressource après s'être authentifié à l'aide de ses informations d'identification. Ces jetons associés au propriétaire de la ressource sont ensuite utilisés par le client (une application ou un service tiers) pour accéder aux ressources protégées..
Ces informations d'identification de jeton ont une durée de vie limitée et peuvent être révoquées par le serveur à la demande du propriétaire de la ressource..
Le flux OAuth va comme suit:
Accentsconagua
oauth_consumer_key: fourni par le serveuroauth_timestampoauth_nonceoauth_signatureoauth_signature_methodserment_appeloauth_version (optionnel)oauth_tokenoauth_token_secretoauth_callback_confirmedoauth_token obtenu à l'étape précédente de l'URI du point de terminaison Autorisation du propriétaire de la ressource.oauth_callback L'URI a été fourni dans la première étape, le serveur redirige le client vers cet URI et ajoute les éléments suivants en tant que chaîne de requête: oauth_token: obtenu dans la deuxième étapeoauth_verifier: utilisé pour s'assurer que le propriétaire de la ressource qui a accordé l'accès est identique au clientoauth_callback L’URI n’a pas été fourni à la première étape, puis le serveur affiche la valeur de oauth_verifier afin que le propriétaire de la ressource puisse informer le client manuellement.oauth_verfier, le client demande au serveur des informations d'identification de jeton en envoyant une demande à l'URI de noeud final de demande de jeton. Cette demande contient les éléments suivants: oauth_token: obtenu dans la deuxième étapeoauth_verfier: obtenu à l'étape précédenteoauth_consumer_key: fourni par le fournisseur de ressources (le serveur), avant de commencer la poignée de main oauthoauth_signatureoauth_signature_methodoauth_nonceoauth_versionoauth_tokenoauth_token_secretLes informations ci-dessus peuvent soit être transportées par une chaîne de requête ajoutée à la demande des URI, soit en les incluant dans Autorisation en-tête, bien que ce dernier soit recommandé en raison d'une meilleure sécurité.
Ce processus est long et devrait être pris en compte lors du développement de nos propres clients pour interagir avec l'API. Le but du client est de gérer tout ce jargon et de faciliter l'utilisateur dans le processus d'authentification. Dans la mesure où nous utiliserons un package fourni par l'équipe de l'API WP REST, les détails ci-dessus seront résumés et nous pourrons obtenir des informations d'identification de jetons en un minimum d'étapes..
Dans la discussion ci-dessus, nous avons rencontré trois adresses URI d'extrémité, à savoir:
Ces URI sont fournis par le serveur de différentes manières. L'une de ces méthodes consiste à les exposer dans la réponse du serveur lors de la vérification de l'API. L'API d'authentification OAuth pour l'API REST WordPress utilise la même méthode, comme nous le verrons dans la section suivante..
Après avoir examiné le fonctionnement d’OAuth, nous allons maintenant installer et activer l’API d’authentification OAuth pour WordPress..
L'API d'authentification OAuth pour WordPress permet au serveur d'accepter les demandes authentifiées à l'aide de l'implémentation OAuth. Il est construit sur les spécifications OAuth 1.0a et les étend par un paramètre supplémentaire-wp_scope-être envoyé au Demande d'informations d'identification temporaire point final. le wp_scope Ce paramètre définit l'étendue de l'accès accordé au client. Vous en trouverez plus dans la documentation officielle sur GitHub.
Le plugin est disponible sur Github à partir de l'équipe API WP REST et ne prend en charge que la version 4.4 ou ultérieure de WordPress..
Clonons le plugin en naviguant vers le / wp-content / plugins / annuaire:
$ git clone https://github.com/WP-API/OAuth1.git
Une fois le téléchargement terminé, activez le plug-in à l'aide de WP CLI:
plugin $ wp activer OAuth1
Sinon, vous pouvez également l'activer en naviguant dans votre navigateur jusqu'à votre section plugins d'administrateur WordPress si vous ne souhaitez pas utiliser WP CLI..
C’est tout ce qui est nécessaire pour permettre au serveur d’accepter OAuth comme méthode d’autorisation. Nous devons ensuite envoyer une demande au serveur pour vérifier si l'API OAuth est prête à être utilisée..
Avant de lancer la négociation OAuth, nous devons d’abord vérifier si l’API est activée sur le serveur. Ceci est fait en envoyant un simple OBTENIR demande au/ wp-json / point de terminaison, puis analyse de la réponse envoyée par le serveur.
Lancez votre client HTTP et envoyez une demande au / wp-json / point final comme suit:
OBTENIR http: // votre-serveur-dev / wp-json /
Cela retournera une réponse JSON comme suit:
Notre objectif ici est la oauth1 valeur dans le authentification valeur de la propriété. Cet objet a les propriétés suivantes définies:
demande: le point de terminaison de la demande d'informations d'identification temporairesautoriser: le noeud final d'autorisation du propriétaire de la ressourceaccès: le noeud final de la demande de jetonversion: la version de OAuth utiliséeLes trois premiers d'entre eux sont des URL absolues que nous avons rencontrées lorsque nous avons découvert le mécanisme OAuth dans une section précédente..
le oauth1 objet défini dans le authentification la valeur de la propriété indique que l'API OAuth a été activée avec succès pour notre site WordPress et que nous pouvons commencer à l'utiliser.
Si l’API OAuth n’est pas activée pour un site, la réponse du serveur contiendra un autorisation valeur de la propriété comme suit:
Maintenant que nous avons installé le plug-in OAuth1.0a, voyons comment nous pouvons créer et gérer des consommateurs pour nos applications..
Une fois le plug-in OAuth1.0 installé avec succès, nous pouvons créer et gérer des consommateurs pour nos applications en accédant à l'administrateur WordPress, puis Utilisateurs> Applications page.
Sur ce Applications enregistrées page, nous pouvons enregistrer une nouvelle application en cliquant sur le bouton Ajouter, puis en remplissant les trois champs suivants de la page résultante:
Une fois créé en cliquant sur le Économiser le consommateur bouton, le Clé client et Secret du client les paramètres apparaîtront au bas de la page pour ce consommateur particulier.
Celles-ci Clé client et Secret du client les paramètres agissent comme oauth_consumer_key et oauth_consumer_secret paramètres respectivement.
Nouveau Secret du client peut être créé en cliquant sur le Regenerate Secret bouton en bas de page.
Le plug-in OAuth expose également la fonctionnalité permettant de créer un consommateur dans la console via le plug-in WP CLI. Ainsi, un nouveau consommateur peut également être créé à l'aide de la commande suivante dans le terminal:
wp oauth1 add --name =--description =
Ce consommateur nouvellement créé apparaîtra alors sur le Applications enregistrées page où vous pouvez l'éditer.
Après avoir enregistré notre application, nous sommes maintenant prêts à commencer le processus d'autorisation OAuth dans les sections suivantes..
Veuillez noter qu'au moment de la rédaction de ce tutoriel, le plug-in OAuth1.0a ne prend plus en charge le package CLI client. Le package CLI client peut être mis à jour dans un avenir proche pour fonctionner avec la dernière version du plug-in OAuth, mais pour le moment, reportez-vous à la section suivante sur la génération d'informations d'identification OAuth à l'aide d'un client HTTP..
Le package Client-CLI de l'équipe API WP REST permet une interaction à distance avec un site WordPress à l'aide de WP-CLI et de l'API WP REST. La source peut être trouvée sur GitHub.
Pour utiliser ce package, vous devez avoir installé et activé les éléments suivants sur le serveur sur lequel se trouve votre installation WordPress:
Sur la machine (ou le client) à partir de laquelle vous souhaitez générer des demandes, les éléments suivants doivent être installés:
Vous pouvez trouver les instructions pour installer les paquets ci-dessus sur leurs sites respectifs.
Cela dit, clonons 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 paquet à l'aide de Composer:
$ cd client-cli $ composer installer
Si tout se passe bien, la ligne de commande devrait afficher quelque chose de similaire au suivant:
Maintenant que nous avons installé le package, nous sommes prêts à générer des identifiants de jeton et à interagir à distance avec l'API REST WordPress à l'aide d'OAuth..
Pour démarrer le processus d'autorisation OAuth, nous obtenons d'abord les éléments suivants auprès du serveur:
oauth_consumer_keyoauth_consumer_secretCela peut être généré en dirigeant le terminal vers votre répertoire d'installation WordPress sur le serveur et en exécutant la commande WP CLI suivante:
$ wp oauth1 add
Cela générera une sortie comme celle-ci:
le Clé et Secret obtenu voici les oauth_consumer_key et oauth_consumer_secret respectivement.
Nous devons maintenant relier le client à notre site WordPress. Sur le client, accédez au client-cli répertoire que vous avez cloné dans la section précédente et exécutez la commande suivante:
$ wp --require = client.php api oauth1 se connecte http: // votre-dev-server / --key =--secret =
Remplacez l'URL ainsi que la clé et le secret que vous avez obtenus à l'étape précédente de la commande ci-dessus. Le résultat devrait ressembler à ceci:
$ wp - est requis = client.php api oaut1 connecte http: // localserver / wordpress-api / --key = kXZMTt3O5hBZ --secret = ueDNeCf-ssi-ssi-ssi-ssi-ss-ss-ss-ss-ss ? oauth_token = wFxrd8OzcIL6lSRkLmmvViIe Entrez le code de vérification:
Accédez à l’URL indiquée par le serveur et authentifiez-vous en cliquant sur le bouton Autoriser bouton:
On vous présentera le jeton de vérification (ou le oauth_verifier) sur l'écran suivant:
Copiez le vérificateur et collez-le dans votre terminal. Vous recevrez un Clé et un Secret, qui sont fondamentalement votre oauth_token et oauth_token_secret respectivement:
Vous pouvez utiliser ces informations d'identification de jeton dans votre client HTTP ou dans toute autre application prenant en charge l'envoi de requêtes authentifiées à l'aide de l'API OAuth..
Puisque le plug-in de serveur OAuth 1.0a suit le flux à trois branches, la génération d'informations d'identification OAuth implique trois étapes:
Commençons par implémenter chacune des étapes ci-dessus à l’aide d’un client HTTP, c’est-à-dire Postman..
Pour acquérir des identifiants temporaires, nous envoyons un POSTER demande au / oauth1 / request point final. Ce point de terminaison de demande d'informations d'identification temporaires doit être détecté automatiquement, car un serveur peut remplacer cette route par la sienne. Nous avons examiné la fonctionnalité de découverte automatique tout en évaluant la disponibilité de l'API OAuth dans une section précédente..
le POSTER demande doit inclure le oauth_consumer_key et oauth_consumer_secret les paramètres acquis lors de l’enregistrement d’un consommateur pour l’application. La demande peut également inclure le oauth_callback paramètre et cette URL de rappel doivent correspondre au schéma, à l'hôte, au port et au chemin de l'URL de rappel fournis lors de l'enregistrement de l'application.
Séparé de oauth_consumer_key et oauth_consumer_secret paramètres, la demande doit également inclure la oauth_signature et oauth_signature_method paramètres. Lors de l'utilisation de Postman, le oauth_signature est généré automatiquement et nous avons juste besoin de spécifier le oauth_signature_method paramètre. Actuellement, seuls les HMAC-SHA1 La méthode de signature est supportée par le plugin serveur OAuth.
Les paramètres ci-dessus peuvent être passés de l’une des manières suivantes:
Autorisation entêteOBTENIR) paramètres de requête dans l'URLPOSTER) paramètres du corps de la demande. Le type de contenu dans ce cas devrait être application / x-www-form-urlencoded.C'est à vous d'utiliser l'une de ces méthodes pour envoyer ces paramètres au serveur..
Commençons maintenant le processus en mettant à feu Postman et en envoyant un message. POSTER requête au point de terminaison de la demande d'informations d'identification temporaires. Mais avant cela, copiez le La clé du consommateur et Secret du consommateur les paramètres fournis par la nouvelle application enregistrée, car ils seront nécessaires à cette étape.
Configurer Postman pour envoyer un POSTER demander à votre point de terminaison des informations d'identification de jeton temporaire. Puis dans le Autorisation onglet, sélectionnez le OAuth 1.0 option de la liste déroulante. Remplissez le La clé du consommateur et Secret du consommateur champs avec les valeurs fournies par le consommateur. Assurez-vous de vérifier que le Méthode Signature l'option est définie sur HMAC-SHA1.
Nous n'avons pas besoin d'entrer d'autres valeurs que celles-ci. Clique le Demande de mise à jour bouton et enfin envoyer la demande en cliquant sur le bouton Envoyer bouton.
S'il n'y a pas d'erreur, le serveur retournera un 200 - OK code de statut avec le corps de réponse ayant un type de contenu de application / x-www-form-urlencoded. Ce corps de requête ressemble à la chaîne de texte suivante:
oauth_token = tyNCKaL3WAJXib5SI6jCnr4P & oauth_token_secret = 1GiImP2XBacmk4FhcEFtqqENs3Bt6Q1m3zDf5s0Rk2kDJyTo & associez-vous
Ce corps de réponse contient trois paramètres pour la prochaine étape du flux à trois branches. Ces trois paramètres sont:
oauth_token: Jeton temporaire OAuth pour l'étape d'autorisation.oauth_token_secret: Un secret temporaire à utiliser oauth_token.oauth_callback_confirmed: Ce paramètre est toujours renvoyé, que vous fournissiez ou non le oauth_callback paramètre dans la première étape.Avec ces informations d'identification temporaires prêtes, nous sommes prêts pour l'étape d'autorisation de l'utilisateur.
Pour l’étape d’autorisation de l’utilisateur, nous ouvrons le noeud final d’autorisation du propriétaire de la ressource dans le navigateur et transmettons le message. oauth_token et oauth_token_secret comme obtenu à l'étape précédente en tant que paramètres de requête comme suit:
http: // votre-dev-serveur / oauth1 / authorize? oauth_token =& oauth_token_secret =
Le navigateur vous demandera de vous connecter à WordPress (si vous ne l'êtes pas déjà) et vous demandera ensuite d'autoriser l'application:
Ici Application impressionnante est le nom de l'application enregistrée.
Autorisez l'application en cliquant sur le bouton Autoriser et vous verrez un jeton de vérification sur l'écran suivant:
Ce jeton agit comme le oauth_verifier jeton à l'étape suivante.
Une fois que l'utilisateur a autorisé le client, l'application apparaîtra sous le Applications autorisées section sur le Utilisateurs> Votre profil page.
La prochaine et dernière étape du flux à trois branches est l’échange de jetons. Dans cette étape, les jetons temporaires obtenus lors de la première étape sont échangés contre un jeton de longue durée de vie pouvant être utilisé par le client..
Pour lancer le processus d’échange de jetons, revenez à Postman et configurez-le pour envoyer un message. POSTER demande au noeud final de demande de jeton.
En utilisant le OAuth 1.0 option à nouveau dans le Autorisation onglet, remplissez les champs pour La clé du consommateur et Secret du consommateur avec les valeurs fournies par le consommateur. Pour le Jeton et Token Secret champs, utilisez les valeurs du oauth_token et oauth_token_secret paramètres (informations d'identification temporaires) obtenus lors de la première étape.
Comme nous pouvons également passer des paramètres dans l’URL en tant que paramètres de requête, ajoutez le oauth_verifier paramètre à l'URL comme suit:
http: // votre-dev-serveur / oauth1 / access? oauth_verifier =
Avec tous les paramètres en place, envoyez la demande en cliquant sur le bouton Envoyer bouton. Si tout se passe bien, le serveur retournera un 200 - OK code de statut avec le corps de réponse contenant oauth_token et oauth_token_secret paramètres.
oauth_token =& oauth_token_secret =
À ce stade, les jetons temporaires acquis lors de la première étape sont rejetés et ne peuvent plus être utilisés..
Ces nouveaux oauth_token et oauth_token_secret les paramètres sont vos informations d'identification OAuth que vous pouvez utiliser dans votre client pour générer des requêtes authentifiées.
Maintenant que nous avons obtenu nos identifiants de jetons, nous pouvons envoyer une demande de test au serveur à l'aide de Postman pour voir s'ils fonctionnent (bien sûr, ils le feront!)..
Nous allons envoyer un EFFACER demande au serveur de supprimer une publication dont l'identifiant est 50. Cet identifiant peut être différent dans votre cas..
Avant de commencer, vous devez disposer des éléments suivants:
oauth_consumer_key: obtenu dans la première étapeoauth_consumer_secret: obtenu dans la première étapeoauth_token: obtenu à l'étape finaleoauth_token_secret: obtenu à l'étape finaleSélectionner OAuth 1.0 de la liste déroulante sous la Autorisation dans Postman, et remplissez les quatre premiers champs comme indiqué ci-dessus. Voici ce à quoi il ressemble:
Clique le Demande de mise à jour bouton après avoir rempli les champs. Vérification du Ajouter des paramètres à l'entête option envoie les paramètres dans l'en-tête de la requête au lieu de les ajouter dans une chaîne de requête.
Envoyez la demande et vous devriez obtenir un 200 - OK code d'état du serveur, indiquant que la publication a été supprimée avec succès.
Dans ce long didacticiel, nous avons présenté la méthode d’authentification OAuth et son fonctionnement pour fournir un accès délégué sécurisé à des applications et services tiers. Nous avons également configuré l'API d'authentification OAuth pour WordPress sur le serveur et l'avons utilisée conjointement avec un client HTTP pour obtenir les informations d'identification du jeton..
Dans la prochaine partie de cette série, nous examinerons la possibilité de récupérer du contenu via l’API WP REST. Alors restez à l'écoute…
