API WP REST: Configuración y uso de la autenticación Oauth 1.0a

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 del oauth_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 ser application/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 con oauth_token.
oauth_callback_confirmed: estos parámetros siempre se devuelven ya sea que proporcione o no el parámetro oauth_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...