Guía de autenticación de la API REST de WordPress

Introducción a la autenticación de la API REST de WordPress

La API REST de WordPress es una herramienta potente que permite acceder al contenido y a las funcionalidades de WordPress mediante peticiones HTTP desde cualquier aplicación, ya sea una aplicación móvil, un frontend en JavaScript, un servicio externo o una aplicación web completamente independiente. Sin embargo, aunque la lectura de contenido público suele estar disponible sin autenticación, crear, actualizar y eliminar contenido requiere que el usuario se autentique para que WordPress sepa quién realiza la acción y si tiene los permisos necesarios.

WordPress admite varios métodos de autenticación para la API REST, y cada uno tiene sus ventajas, inconvenientes y escenarios de uso ideales. La elección del método adecuado depende de quién accede a la API (frontend en el mismo sitio, aplicación externa, aplicación móvil), del nivel de seguridad necesario y de la complejidad de la integración que quieras implementar. En esta guía analizamos cada método en detalle con ejemplos prácticos.

Autenticación por cookies con nonce

La autenticación por cookies es el método predeterminado para las peticiones que provienen del propio sitio de WordPress, normalmente desde código JavaScript en el panel de administración o en el frontend. Cuando el usuario ha iniciado sesión en WordPress, el navegador envía automáticamente una cookie con cada petición y la API REST de WordPress la utiliza para identificar al usuario. No obstante, la cookie por sí sola no es suficiente, ya que eso permitiría ataques CSRF en los que un sitio malicioso podría desencadenar peticiones en nombre del usuario autenticado.

Cómo funciona el nonce

WordPress utiliza el nonce (number used once, número usado una sola vez) como una capa adicional de protección contra ataques CSRF. El nonce es un token de duración limitada que WordPress genera para el usuario autenticado y que debe enviarse con cada petición que modifique datos (POST, PUT, DELETE). El código JavaScript lo obtiene mediante la función wp_localize_script() o la variable global wpApiSettings.nonce en el panel de administración.

• Generación - wp_create_nonce('wp_rest') en el lado del servidor
• Transmisión - wp_localize_script() para pasar el nonce a JavaScript
• Envío - cabecera X-WP-Nonce o parámetro de consulta _wpnonce
• Validez - el nonce caduca tras 24 horas (dos periodos de nonce de WordPress de 12 h)
• Revalidación - para sesiones de larga duración, solicita periódicamente un nuevo nonce a través de la API

La autenticación por cookies es ideal para el código JavaScript que se ejecuta en el propio sitio de WordPress, porque no requiere ninguna configuración adicional más allá de pasar correctamente el nonce. No es adecuada para aplicaciones externas, ya que estas no pueden acceder a la cookie de WordPress. Además, ten en cuenta que el nonce caduca y que las sesiones de larga duración requieren un mecanismo de actualización del token para que el usuario no reciba un error 403 a mitad del trabajo.

Contraseñas de aplicación (Application Passwords)

Las contraseñas de aplicación se introdujeron en WordPress 5.6 como un método integrado para autenticar aplicaciones externas sin entregar la contraseña principal del usuario. Cada usuario puede crear varias contraseñas de aplicación con nombres descriptivos (por ejemplo, App móvil, Integración Zapier, Script personalizado) y cada una puede revocarse de forma independiente sin afectar a las demás ni a la contraseña principal del usuario.

Creación y uso

La contraseña de aplicación se crea en el panel de administración de WordPress, en Usuarios, Editar usuario, sección Contraseñas de aplicación. Introduces el nombre de la aplicación y WordPress genera una contraseña de 24 caracteres agrupada en 4 grupos de 6 caracteres separados por espacios. Esta contraseña se usa para la autenticación HTTP Basic, donde el nombre de usuario y la contraseña de aplicación se envían en la cabecera Authorization codificados en formato base64.

Una petición con una contraseña de aplicación tiene el aspecto de un HTTP Basic Auth estándar: la cabecera Authorization contiene Basic seguido de la cadena codificada en base64 username:application_password. Los espacios de la contraseña se ignoran, así que puedes eliminarlos o dejarlos. WordPress reconoce automáticamente que se trata de una contraseña de aplicación y no de la contraseña principal del usuario, y aplica los permisos correspondientes.

Ventajas y limitaciones

• Sencillez - funcionalidad integrada sin necesidad de plugins
• Control granular - cada aplicación tiene su propia contraseña que puede revocarse
• Registro - WordPress registra el último uso de cada contraseña de aplicación
• Limitación - solo funciona sobre HTTPS, porque Basic Auth envía las credenciales en cada petición
• Limitación - no hay granularidad de scope ni de permisos más allá del rol del usuario

Las contraseñas de aplicación son una excelente opción para integraciones servidor a servidor, ideales para entornos de hosting VPS, scripts de automatización y aplicaciones en las que la sencillez es más importante que el control de acceso granular. Utiliza siempre HTTPS, porque las credenciales se envían en cada petición y, sin HTTPS, pueden ser interceptadas. Para integraciones en producción, crea un usuario de WordPress independiente con los permisos mínimos necesarios en lugar de usar una cuenta de administrador.

OAuth 2.0

OAuth 2.0 es un estándar del sector para la autorización utilizado por Google, Facebook, GitHub y muchos otros servicios. WordPress no incluye soporte nativo para OAuth, pero está disponible mediante plugins como WP OAuth Server y OAuth 2.0 Provider. OAuth es ideal para escenarios en los que quieres permitir que aplicaciones de terceros accedan a tu API de WordPress con un control preciso de los permisos y sin compartir las credenciales del usuario.

Flujo de OAuth 2.0

El flujo de OAuth más habitual para aplicaciones web es el flujo Authorization Code, compuesto por varios pasos. La aplicación redirige al usuario al endpoint de autorización de WordPress, donde el usuario aprueba el acceso. WordPress redirige al usuario de vuelta a la aplicación con un código de autorización. La aplicación intercambia el código por un token de acceso llamando al endpoint de token. El token de acceso se utiliza después en las peticiones a la API en la cabecera Authorization Bearer.

• Authorization Code - el flujo más seguro para aplicaciones web con servidor
• Implicit - para aplicaciones SPA sin servidor (menos seguro, normalmente no recomendado)
• Client Credentials - para comunicación servidor a servidor sin contexto de usuario
• PKCE - Proof Key for Code Exchange, mejora la seguridad de las aplicaciones móviles y SPA

OAuth ofrece el mayor nivel de control y seguridad, pero también es el más complejo de implementar. Los tokens de acceso tienen una duración limitada y los refresh tokens se utilizan para obtener nuevos sin necesidad de volver a autorizar al usuario. El parámetro scope define qué permisos solicita la aplicación, lo que da al usuario transparencia sobre lo que la aplicación puede hacer con sus datos.

JWT (JSON Web Tokens)

La autenticación JWT es una alternativa popular para el acceso a la API REST que utiliza tokens en lugar de sesiones. Un token JWT es una cadena firmada que contiene información sobre el usuario y los permisos, y que se envía en la cabecera Authorization de cada petición. WordPress no incluye soporte nativo para JWT, pero está disponible mediante plugins como JWT Authentication for WP REST API y Simple JWT Login.

Cómo funciona JWT

El usuario envía el nombre de usuario y la contraseña al endpoint de token (normalmente /wp-json/jwt-auth/v1/token) y recibe un token JWT como respuesta. Este token se envía después en la cabecera Authorization: Bearer de todas las peticiones a la API. El servidor verifica la firma del token y extrae la información del usuario sin necesidad de consultar la base de datos, lo que hace que JWT sea más eficiente para API con mucha carga.

El token JWT consta de tres partes separadas por puntos: cabecera (algoritmo y tipo de token), payload (datos del usuario, tiempo de caducidad, emisor) y firma (firma criptográfica que garantiza la integridad del token). El token puede descodificarse en el lado del cliente, pero no puede falsificarse sin la clave secreta que solo conoce el servidor. Esto permite que el cliente lea la información del usuario desde el token sin necesidad de una llamada adicional a la API.

Ventajas de JWT

• Sin estado - el servidor no almacena sesiones, lo que facilita el escalado
• Autocontenido - el token contiene toda la información necesaria del usuario
• Cross-domain - funciona con distintos dominios sin los problemas de CORS de las cookies
• Aplicaciones móviles - ideal para apps móviles que no utilizan cookies
• Rendimiento - la verificación del token no requiere consultar la base de datos

Comparación de los métodos de autenticación

La elección del método de autenticación depende de tu escenario concreto. Las cookies y el nonce son ideales para JavaScript en el mismo sitio, porque no requieren configuración adicional. Consulta nuestros planes de hosting WordPress para disponer de un entorno óptimo. Las contraseñas de aplicación son la mejor opción para integraciones servidor a servidor sencillas y scripts, porque están integradas y son fáciles de usar. OAuth 2.0 es la opción adecuada para aplicaciones de terceros en las que se necesita un control de acceso granular y la autorización del usuario. JWT es óptimo para aplicaciones móviles y frameworks SPA que se comunican con WordPress como CMS headless.

Recomendaciones de seguridad

• Usa siempre HTTPS - todos los métodos de autenticación requieren una conexión cifrada
• Permisos mínimos - crea usuarios con solo los permisos necesarios para el acceso a la API
• Rotación de tokens - implementa refresh tokens y una caducidad corta de los tokens de acceso
• Limitación de peticiones - limita el número de peticiones por usuario como protección contra ataques de fuerza bruta
• Registro - registra todas las peticiones a la API para su auditoría y para detectar actividades maliciosas
• Configuración de CORS - restringe el acceso a la API únicamente desde los dominios permitidos

Para aplicaciones en producción, recomendamos una combinación de varios métodos en la que cada uno cubra un escenario diferente. Autenticación por cookies para las interacciones del panel de administración y el frontend, contraseñas de aplicación para scripts internos y automatización, JWT para aplicaciones móviles y OAuth para integraciones de terceros. Revisa periódicamente los tokens activos y las contraseñas de aplicación, y revoca aquellos que ya no estén en uso, porque cada token activo es un posible vector de ataque.