Spanish (Español) translation by Elías Nicolás (you can also view the original English article)
En la parte anterior de la serie, configuramos la autenticación HTTP básica en el servidor mediante la instalación del complemento disponible en GitHub por parte del equipo WP REST API. El método de autenticación básico nos permite enviar solicitudes autenticadas mediante el envío de credenciales de inicio de sesión en el encabezado de la solicitud. Si bien es rápido y práctico, también existe la posibilidad de que estas credenciales caigan en manos equivocadas. Por lo tanto, este método solo se debe utilizar en redes seguras para fines de desarrollo y pruebas únicamente.
Para utilizar la autenticación en servidores de producción, debe haber una forma más segura de enviar solicitudes autenticadas sin correr el riesgo de exponer las credenciales de inicio de sesión. Gracias al método de autenticación OAuth, esas solicitudes se pueden enviar sin exponer el nombre de usuario y la contraseña de una manera insegura.
En la parte actual de la serie, aprenderemos a configurar y usar el método de autenticación OAuth para usarlo con el complemento WP REST API. Para ser específico, vamos a:
- tomar una visión general del método de autenticación OAuth y cómo funciona
- instalar el complemento del servidor OAuth
- generar un token de acceso OAuth para usar en nuestra aplicación
Comencemos presentándonos al método de autenticación OAuth.
Presentamos la Autenticación de OAuth
¿Qué haces cuando necesitas iniciar sesión en tu administrador de WordPress? Simplemente vaya a la página de inicio de sesión e ingrese sus credenciales de inicio de sesión, ¿verdad? ¡Así de simple! Pero, ¿qué sucede si está utilizando un servicio externo que requiere acceso a sus recursos de WordPress (publicaciones, páginas, medios o cualquier otra cosa)? ¿Simplemente entregaría sus credenciales de inicio de sesión a ese servicio, sabiendo que podrían terminar en manos equivocadas cada vez que la integridad de ese servicio se vea comprometida? La respuesta probablemente sería "No".
En el modelo tradicional de autenticación, hay dos roles:
- El cliente: puede ser un usuario, aplicación o servicio
- El proveedor de recursos: el servidor donde se encuentran
los recursos protegidos
Si un cliente desea acceder a los recursos protegidos, se autenticará proporcionando las credenciales apropiadas al servidor y se le otorgará acceso.
El problema surge cuando un servicio de terceros necesita acceso a estos recursos protegidos en el servidor. El usuario no puede (y no debe) proporcionar credenciales para acceder a los recursos. Proporcionar credenciales a un tercero significa ceder el control total sobre el recurso ubicado en el servidor.
Ahí es donde la metodología de autenticación OAuth viene al rescate. Introduce un nuevo rol en el proceso de autenticación, y es el propietario del recurso. Ahora hay tres roles en el proceso de autenticación:
- El cliente: no el usuario en sí, sino una aplicación o servicio de un tercero que actúa en nombre del usuario y accede a recursos protegidos
- El servidor: el servidor donde se encuentran los recursos protegidos
- El propietario del recurso: el usuario mismo
Los tres roles anteriores juntos crean lo que se denomina autenticación OAuth de tres patas. El número de patas define las funciones involucradas en un proceso de autenticación. Cuando el propietario del recurso también es el cliente, el flujo se conoce como autenticación de dos patas.
De acuerdo con Webopedia:
OAuth es un estándar de autorización abierto que se utiliza para proporcionar acceso de aplicaciones de cliente seguro a los recursos del servidor. El marco de autorización OAuth permite a una aplicación de terceros obtener acceso limitado a un servicio HTTP, ya sea en nombre de un propietario de un recurso o permitiendo que la aplicación de terceros obtenga acceso en su propio nombre.
OAuth permite a los propietarios del servidor autorizar el acceso a los recursos del servidor sin compartir las credenciales. Esto significa que el usuario puede otorgar acceso a recursos privados de un servidor a otro recurso del servidor sin compartir su identidad.
Por lo tanto, en el flujo de autenticación de OAuth, el usuario no necesita exponer las credenciales, pero puede autorizar al cliente a actuar en su nombre, al decidir a qué recursos puede acceder el cliente. En otras palabras, si bien no proporciona credenciales de inicio de sesión, el usuario también puede decidir el alcance del acceso que se le otorga al cliente.
Esto permite que no solo los sitios web, sino también las aplicaciones de escritorio y móviles obtengan acceso limitado a un recurso en un servidor.
En términos de WordPress, OAuth informa al proveedor de recursos (la instalación de WordPress) que el propietario del recurso (el usuario de WordPress) ha otorgado permiso para acceder a una aplicación de terceros para acceder a sus recursos. Estos recursos pueden ser cualquier cosa como publicaciones, páginas, taxonomía y medios, etc. Este permiso puede ser de acceso limitado o completo, como veremos más adelante en este tutorial.
Cómo funciona el flujo de autenticación de OAuth
La API de autenticación de OAuth para WordPress se basa en las especificaciones de OAuth 1.0a, por lo tanto, veremos cómo funciona OAuth 1.0a.
OAuth funciona mediante el uso de credenciales de tokens emitidas por el proveedor de recursos (el servidor), a petición del propietario del recurso después de que se haya autenticado utilizando sus credenciales. Estos tokens, asociados con el propietario del recurso, son utilizados por el cliente (una aplicación o servicio de terceros) para obtener acceso a los recursos protegidos.
Estas credenciales de token tienen una vida útil limitada y el servidor puede revocarlas a petición del propietario del recurso.
El flujo de OAuth es el siguiente:
- El cliente
envía una solicitud firmada al servidor para obtener un Token de
solicitud Request Token, también conocido como credenciales temporales Temporary Credentials. Esta solicitud se envía al URI de punto final de credenciales temporales Temporary Credentials y contiene lo siguiente:
-
oauth_consumer_key
: proporcionada por el servidor -
oauth_timestamp
-
oauth_nonce
-
oauth_signature
-
oauth_signature_method
-
oath_callback
-
oauth_version
(opcional)
-
- El servidor verifica la solicitud y, si es válida, concede un token de solicitud que contiene:
-
oauth_token
-
oauth_token_secret
-
oauth_callback_confirmed
-
- El cliente luego envía al propietario del recurso (el usuario) al servidor para autorizar la solicitud. Esto
se hace mediante la construcción de un URI de solicitud agregando
oauth_token
obtenido en el paso anterior al URI del punto final de autorización del propietario del recurso. - El propietario del recurso (el usuario) autoriza en el servidor proporcionando credenciales.
- Si
se proporcionó el URI
oauth_callback
en el primer paso, el servidor redirige el cliente a ese URI y agrega lo siguiente como cadena de consulta:-
oauth_token
: obtenido en el segundo paso -
oauth_verifier
: se utiliza para garantizar que el propietario del recurso que otorgó el acceso sea el mismo devuelto al cliente
-
- Si
no se proporcionó el URI
oauth_callback
en el primer paso, el servidor muestra el valor deloauth_verifier
para que el propietario del recurso pueda informarlo al cliente manualmente. - Después
de recibir
oauth_verfier
, el cliente solicita al servidor las credenciales del token enviando una solicitud al URI del punto final de la solicitud Token. Esta solicitud contiene lo siguiente:-
oauth_token
: obtenido en el segundo paso -
oauth_verfier
: obtenido en el paso anterior -
oauth_consumer_key
: proporcionada por el proveedor de recursos (el servidor), antes de iniciar el saludo de Oauth -
oauth_signature
-
oauth_signature_method
-
oauth_nonce
-
oauth_version
-
- El servidor verifica la solicitud y concede lo siguiente, conocido como credenciales de token:
-
oauth_token
-
oauth_token_secret
-
- El cliente luego usa credenciales de tokens para acceder a recursos protegidos en el servidor.
La información anterior puede transportarse mediante una cadena de
consulta adjuntada para solicitar URI o incluyéndola en el encabezado
Authorization
, aunque esta última se recomienda debido a una mayor
seguridad.
Este es un proceso largo y debe tenerse en cuenta al desarrollar nuestros propios clientes para interactuar con la API. El objetivo del cliente es administrar toda esta jerga y facilitar al usuario el proceso de autenticación. Dado que utilizaremos un paquete proporcionado por el equipo de la API REST de WP, los detalles anteriores se eliminarán y podremos obtener credenciales de token en un número mínimo de pasos.
En la discusión anterior, encontramos tres URI de punto final, a saber:
- Endpoint de solicitud de credencial temporal
- Endpoint de autorización del propietario del recurso
- Credenciales de testigo Solicitud de endpoint
Estos URI son provistos por el servidor de varias maneras. Una de estas formas es exponiéndolas en la respuesta del servidor cuando se comprueba la API. La API de autenticación OAuth para la API REST de WordPress utiliza el mismo método, como veremos en la siguiente sección.
Después de analizar cómo funciona OAuth, nuestro siguiente paso es instalar y habilitar la API de autenticación de OAuth para WordPress.
Instalación de la API de Autenticación de OAuth para WordPress
La
API de autenticación de OAuth para WordPress permite al servidor
aceptar solicitudes autenticadas mediante la implementación de OAuth. Se
basa en las especificaciones de OAuth 1.0a y las amplía mediante un
parámetro adicional, wp_scope
, que se enviará al punto final de la
solicitud de credencial temporal Temporary Credential Request . El parámetro wp_scope
define el
alcance del acceso otorgado al cliente. Puede encontrar más información
al respecto en la documentación oficial de GitHub.
El complemento está disponible en Github desde el equipo de WP REST API y solo es compatible con la versión 4.4 o posterior de WordPress.
Vamos a clonar el complemento navegando al directorio /wp-content/plugins/
:
$ git clone https://github.com/WP-API/OAuth1.git
Una vez completada la descarga, active el complemento utilizando WP CLI:
$ wp plugin activate OAuth1
Alternativamente, también puede activarlo navegando por su navegador a la sección de complementos de administración de WordPress si no desea utilizar WP CLI.
Esto es todo lo que se necesita para permitir que el servidor acepte OAuth como un método de autorización. Lo siguiente que debemos hacer es enviar una solicitud al servidor para verificar si la API de OAuth está lista para ser utilizada.
Evaluar la disponibilidad de la API de OAuth
Antes de iniciar el protocolo de enlace
OAuth, primero debemos verificar si la API está habilitada en el
servidor. Esto se hace enviando una simple solicitud GET
al /wp-json/
y luego analizando la respuesta enviada por el
servidor.
Encienda su cliente HTTP y envíe una solicitud al /wp-json/
de la siguiente manera:
GET http://your-dev-server/wp-json/
Esto devolverá una respuesta JSON de la siguiente manera:

Nuestro enfoque aquí es el valor oauth1
en el valor de la propiedad de autenticación authentication
. Este objeto tiene las siguientes propiedades definidas: solicitud:
-
request
:el punto final de la solicitud de credencial temporal -
authorize
: el punto final de Autorización del propietario del recurso -
access
: el punto final de solicitud de token -
version
: la versión de OAuth que se está utilizando
Los tres primeros son URL absolutas que encontramos al conocer el mecanismo de OAuth en una sección anterior.
El
objeto oauth1
definido en el valor de la propiedad de authentication
muestra que la API de OAuth se ha habilitado con éxito para nuestro
sitio de WordPress y podemos comenzar a utilizarla.
Si
la API OAuth no está habilitada para un sitio, la respuesta del
servidor contendría un valor de propiedad authorization
vacía de la
siguiente manera:

Ahora que hemos instalado el complemento OAuth1.0a, veamos cómo podemos crear y gestionar consumidores para nuestras aplicaciones.
Crear y administrar aplicaciones
Una vez que el complemento OAuth1.0 se haya instalado correctamente, podemos crear y administrar consumidores para nuestras aplicaciones visitando el administrador de WordPress y luego a la página Usuarios > Aplicaciones.

En esta página de Aplicaciones registradas, podemos registrar una nueva aplicación haciendo clic en el botón Agregar nuevo y completando los siguientes tres campos en la página resultante:
- Consumer name: el nombre del consumidor. Este nombre se muestra al usuario durante el proceso de autorización y luego, en sus páginas de perfil en la sección Authorized Applications.
- Description: la descripción opcional para la aplicación del consumidor.
- Callback URL: la URL de devolución de llamada. Esta URL de devolución de llamada se usa al generar credenciales temporales, como veremos en el siguiente paso.
Una vez creado al hacer clic en el botón Save Consumer , los parámetros de Client Key y Client Secret aparecerán en la parte inferior de la página para este consumidor en particular.

Estos parámetros de Client Key y Client Secret actúan como oauth_consumer_key
y oauth_consumer_secret
respectivamente.
Se puede crear un nuevo Client Secret haciendo clic en el botón Regenerate Secret en la parte inferior de la página.
El complemento OAuth también expone la funcionalidad para crear un consumidor en la consola a través del complemento WP CLI. Entonces, un nuevo consumidor también puede crearse con el siguiente comando en la terminal:
wp oauth1 add --name=<consumer_name> --description=<consumer_description>
Este consumidor recién creado aparecerá en la página Aplicaciones registradas donde puede editarlo.
Al haber registrado nuestra solicitud, ahora estamos listos para comenzar el proceso de autorización de OAuth en las siguientes secciones.
Instalación del paquete CLI del cliente
Tenga en cuenta que en el momento de escribir este tutorial, el complemento OAuth1.0a ya no es compatible con el paquete CLI del cliente. El paquete Client CLI podría actualizarse en un futuro próximo para funcionar con la última versión del complemento OAuth, pero, por ahora, consulte la siguiente sección sobre cómo generar credenciales OAuth utilizando un cliente HTTP.
El paquete Client-CLI del equipo WP REST API permite la interacción remota con un sitio de WordPress usando WP-CLI y WP REST API. La fuente se puede encontrar en GitHub.
Para utilizar este paquete, deberá tener los siguientes instalados y activados en el servidor donde se encuentra su instalación de WordPress:
- WP CLI
- Complemento API WP REST
- Complemento de
servidor OAuth 1.0a
En la máquina (o cliente) desde la que desea generar solicitudes, se debe instalar lo siguiente:
- WP CLI
- Composer
- El repositorio CLI del cliente en sí
Puede encontrar
las instrucciones para instalar los paquetes anteriores en sus
respectivos sitios.
Dicho esto, clonemos el repositorio en el cliente ejecutando el siguiente comando:
$ git clone https://github.com/WP-API/client-cli
Ahora navegue hacia el directorio clonado e instale las dependencias del paquete usando Composer:
$ cd client-cli $ composer install
Si todo va bien, la línea de comando debería mostrar algo similar a lo siguiente:

Ahora que hemos instalado el paquete, estamos listos para generar credenciales de token e interactuar de forma remota con la API REST de WordPress usando OAuth.
Uso de la CLI de cliente para generar credenciales de OAuth
Para comenzar el proceso de autorización de OAuth, primero obtenemos lo siguiente del servidor:
-
oauth_consumer_key
-
oauth_consumer_secret
Esto se puede generar dirigiendo el terminal a su directorio de instalación de WordPress en el servidor y ejecutando el siguiente comando WP CLI:
$ wp oauth1 add
Esto generará un resultado como el siguiente:

La clave Key
y el secreto Secret
que se obtienen aquí son oauth_consumer_key
y oauth_consumer_secret
, respectivamente.
Ahora tenemos que vincular al cliente a nuestro sitio de WordPress. En el cliente, vaya al directorio cliente-cli clonado en la sección anterior y ejecute el siguiente comando:
$ wp --require=client.php api oauth1 connect http://your-dev-server/ --key=<your key here> --secret=<your secret here>
Reemplace la URL y también la clave y el secreto que obtuvo en el paso anterior en el comando anterior. El resultado debería ser como el siguiente:
$ wp --require=client.php api oauth1 connect http://localserver/wordpress-api/ --key=kXZMTt3O5hBZ --secret=ueDNeCfgNuyNyxkiU3qHGgWZWmGsg5lZwmMyhyjANsyYgz3Q Open in your browser: http://localserver/wordpress-api/oauth1/authorize?oauth_token=wFxrd8OzcIL6lSRkLmmvViIe Enter the verification code:
Navegue a la URL dada por el servidor y autentíquese haciendo clic en el botón Authorize:

Se le presentará el token de verificación (o el oauth_verifier
) en la siguiente pantalla:

Copie el verificador y péguelo en su terminal. Se te dará una Clave Key
y un Secreto Secret
, que son básicamente tu oauth_token
y oauth_token_secret
, respectivamente:

Puede usar estas credenciales de token en su cliente HTTP o cualquier otra aplicación que admita el envío de solicitudes autenticadas utilizando la API de OAuth.
Uso de un cliente HTTP para generar credenciales de OAuth
Como el complemento del servidor OAuth 1.0a sigue el flujo de tres patas, la generación de credenciales de OAuth implica tres pasos:
- Adquisición de credenciales temporales
- Autorizaciones de usuario
- Intercambio de Tokens
Comencemos implementando cada uno de los pasos anteriores utilizando un cliente HTTP, es decir, Postman
1. Adquiriendo Credenciales Temporales
Para adquirir credenciales
temporales, enviamos una solicitud POST
al punto final /oauth1/request
. Este
punto final de solicitud de credenciales temporales se debe descubrir
automáticamente ya que un servidor podría reemplazar esta ruta por la
suya. Revisamos la función de descubrimiento automático al evaluar la
disponibilidad de la API de OAuth en una sección previa.
La
solicitud POST
debe incluir los parámetros oauth_consumer_key
y
oauth_consumer_secret
adquiridos al registrar un consumidor para la
aplicación. La solicitud también puede incluir el parámetro
oauth_callback
y esta
URL de devolución de llamada debe coincidir con el esquema, el host, el
puerto y la ruta de la URL de devolución de llamada que se proporcionó
al registrar la aplicación.
Además
de los parámetros oauth_consumer_key
y oauth_consumer_secret
, la
solicitud también debe incluir los parámetros oauth_signature
y
oauth_signature_method
. Cuando
se utiliza Postman, el oauth_signature
se genera automáticamente y solo
necesitamos especificar el parámetro oauth_signature_method
. Actualmente, solo el método de firma HMAC-SHA1 es compatible con el
complemento del servidor OAuth.
Los parámetros anteriores pueden pasarse de cualquiera de las siguientes tres maneras:
- A través del encabezado
Authorization
- Parámetros de consulta Vía (
GET
) en la URL - Vía
(
POST
) solicitar parámetros del cuerpo. El tipo de contenido en este caso debe serapplication/x-www-form-urlencoded
.
Depende de usted utilizar cualquiera de estos métodos anteriores para enviar estos parámetros al servidor.
Comencemos
ahora el proceso activando Postman y enviando una solicitud POST
al
punto final de la solicitud de credenciales temporales. Pero antes de
eso, copie los parámetros de clave de consumidor Consumer Key y
secreto de consumidor Consumer Secret según lo provisto por la aplicación recién
registrada ya que serán necesarios en este paso.
Configure Postman para
enviar una solicitud POST
a su punto final de credenciales de token
temporal. Luego, en la pestaña Authorization, seleccione la opción OAuth
1.0 del menú desplegable. Complete los campos Clave del consumidor Consumer Key y
Secreto del consumidor Consumer Secret con los valores proporcionados por el consumidor. Asegúrese de verificar que la opción Método de firma Signature Method esté configurada
en HMAC-SHA1.

No necesitamos ingresar ningún valor más que estos. Haga clic en el botón Update Request y finalmente envíe la solicitud haciendo clic en el botón Send.
Si
no hay ningún error, el servidor devolverá un código de estado 200 - OK
junto con el cuerpo de respuesta que tiene un tipo de contenido de
application/x-www-form-urlencoded
. Este cuerpo de solicitud se parece a la siguiente cadena de texto:
oauth_token=tyNCKaL3WAJXib5SI6jCnr4P&oauth_token_secret=1GiImP2XBacmk4FhcEFtqqENs3Bt6Q1m3zDf5s0Rk2kDJyTF&oauth_callback_confirmed=true
Este cuerpo de respuesta contiene tres parámetros para el siguiente paso del flujo de tres patas. Estos tres parámetros son:
-
oauth_token
: un token de OAuth temporal para el paso de autorización. -
oauth_token_secret
: un secreto temporal que se utilizará junto conoauth_token
. -
oauth_callback_confirmed
: estos parámetros siempre se devuelven ya sea que proporcione o no el parámetrooauth_callback
en el primer paso.
Con estas credenciales temporales listas, estamos listos para el paso de autorización del usuario.
2. Autorización de usuario
Para
el paso de autorización del usuario, abrimos el punto final de
autorización del propietario del recurso en el navegador y pasamos el
oauth_token
y oauth_token_secret
como se obtuvo en el paso anterior como
parámetros de consulta como los siguientes:
http://your-dev-server/oauth1/authorize?oauth_token=<token_here>&oauth_token_secret=<secret_here>
El navegador le pedirá que inicie sesión en WordPress (si aún no ha iniciado sesión) y luego le pedirá que autorice la aplicación:

Aquí Awesome Application es el nombre de la aplicación registrada.
Autorice la aplicación haciendo clic en el botón Autorizar y se le presentará un token de verificación en la siguiente pantalla:

Este token actúa como el token oauth_verifier
en el siguiente paso.
Una vez que el usuario haya autorizado al cliente, la aplicación aparecerá en la sección de Aplicaciones autorizadas en la página Usuarios > Su perfil.
3. Intercambio de Tokens
El siguiente y último paso en el flujo de tres patas es el intercambio de tokens. En este paso, los tokens temporales obtenidos en el primer paso se intercambian por un token de larga duración que podría ser utilizado por el cliente.
Para iniciar el proceso de intercambio de tokens, vuelva a
Postman y
configúrelo para enviar una solicitud POST
al endpoint de solicitud
de token.
Al
usar de nuevo la opción OAuth 1.0 en la pestaña Authorization, complete
los campos de Clave del consumidor Consumer Key y Secreto del consumidor Consumer Secret con los
valores proporcionados por el consumidor. Para los campos Token y Token
Secret, use los valores de los
parámetros oauth_token
y oauth_token_secret
(credenciales temporales)
que se obtuvieron en el primer paso.
Como
también podemos pasar parámetros en la URL como parámetros de consulta,
agregue el parámetro oauth_verifier
a la URL de la siguiente manera:
http://your-dev-server/oauth1/access?oauth_verifier=<oauth_verifier_value>
Con todos los parámetros en su lugar, envíe la solicitud haciendo clic en el botón Send. Si
todo va bien, el servidor devolverá un código de estado 200 - OK junto
con el cuerpo de respuesta que contiene los parámetros oauth_token
y
oauth_token_secret
.
oauth_token=<oauth_token_value>&oauth_token_secret=<oauth_secret_value>
En este punto, los tokens temporales adquiridos en el primer paso se descartan y ya no se pueden usar.
Estos
nuevos parámetros oauth_token
y oauth_token_secret
son sus credenciales
de OAuth que puede usar en su cliente para generar solicitudes
autenticadas.
Envío de una solicitud autenticada de prueba
Ahora que hemos obtenido nuestras credenciales de token, podemos enviar una solicitud de prueba al servidor usando Postman para ver si funcionan (¡por supuesto que lo harán!).
Enviaremos
una solicitud DELETE
al servidor para eliminar una publicación con una
identificación de 50. Esta identificación puede ser diferente en su
caso.
Deberá tener lo siguiente antes de comenzar:
-
oauth_consumer_key
: obtenido en el primer paso -
oauth_consumer_secret
: obtenido en el primer paso -
oauth_token
: obtenido en el paso final -
oauth_token_secret
: obtenido en el paso final
Seleccione OAuth 1.0 del menú desplegable en la pestaña Authorization en Postman, y complete los primeros cuatro campos como se mencionó anteriormente. Debajo está lo que parece:

Haga clic en el botón Update Request después de completar los campos. Al marcar la opción Add params to header, se envían los parámetros en el encabezado de la solicitud en lugar de agregarlos en una cadena de consulta.
Envía la solicitud y deberías obtener un código de estado 200 - OK del servidor, que muestre que la publicación se ha eliminado correctamente.
Conclusión
En este largo tutorial tomamos una descripción general del método de autenticación OAuth y cómo funciona para proporcionar un acceso delegado seguro a aplicaciones y servicios de terceros. También configuramos la API de autenticación OAuth para WordPress en el servidor y la usamos junto con un cliente HTTP para obtener credenciales de token.
En la próxima parte de esta serie, buscaremos recuperar contenido a través de la API WP REST. Así que estad atentos...
Subscribe below and we’ll send you a weekly email summary of all new Code tutorials. Never miss out on learning about the next big thing.
Update me weeklyEnvato Tuts+ tutorials are translated into other languages by our community members—you can be involved too!
Translate this post