Claves de API, contraseñas de aplicación y OAuth: cómo deja entrar cada CMS
Hay tres formas de que un gestor de contenidos deje entrar a un programa de fuera, y no son igual de buenas. Una clave o token de API es un secreto que vale por una cuenta. Una contraseña de aplicación es un secreto hecho para una sola aplicación, que aparece en una lista aparte y se revoca sola. OAuth te manda a tu propia web a aprobar la cosa, y ata lo que podrá hacer a lo que puedes hacer tú. La tercera es claramente la mejor y casi nadie la ofrece: de 11 plataformas para las que hemos construido, una.
·
Esto importa más de lo que parece, porque lo que pegues en un producto es toda tu protección. Una credencial que no puedes ver, ni limitar, ni revocar por separado es una credencial sobre la que tienes que fiarte de alguien.
Los tres mecanismos y qué demuestra cada uno
La pregunta útil sobre una credencial no es cuánto ocupa. Es: ¿qué demuestra quien la tiene, y qué pasa cuando quieres recuperarla?
- Un token o clave de API. Una cadena que vale por una cuenta o por un proyecto. Suele enseñarse una sola vez. Suele poder revocarse, aunque a veces solo borrándola y creando otra. Muchas veces se puede limitar: los tokens de Strapi se ciñen a ciertas colecciones, los de Craft se emiten contra un esquema que decide exactamente qué puede leer y cambiar, y los de Sanity tienen niveles, de los cuales el más bajo que escribe es Editor. Una clave limitada es una respuesta francamente buena. Una sin límites que vale por un administrador es lo más débil de esta lista.
- Una contraseña de aplicación. La respuesta de WordPress, y la mejor de las basadas en un secreto. Es una credencial aparte creada para una aplicación, aparece en tu propio perfil con el nombre que le pusiste, solo sirve para la API REST, y borrarla no cambia nada de cómo entras tú. Todo lo que querrías de una clave, con las dos cosas que a las claves suelen faltarles: puedes verla en una lista y puedes quitar una sin tocar las demás.
- OAuth, bien hecho. Te mandan a tu propia web, entras allí, ves qué te están pidiendo y pulsas aprobar. El programa no ve ninguna contraseña tuya, y el acceso que recibe queda atado a ti: tus permisos son sus permisos, y lo retiras desde tu propio panel. Este es el arreglo que usa nuestro propio conector por el otro lado, por exactamente los mismos motivos, lo cual es un argumento razonable de que nos lo creemos.
Qué te pide cada plataforma
Esta tabla se lee del formulario de conexión de cada adaptador, así que es lo que de verdad te van a pedir que pegues. La segunda columna es la que dice algo: una plataforma que necesita saber *quién eres* además de cuál es el secreto suele tener detrás un arreglo mejor.
| Plataforma | Lo que te pide pegar | Y quién eres |
|---|---|---|
| WordPress | Contraseña de aplicación | Tu usuario de WordPress |
| Joomla | Token de API de Joomla | No |
| Drupal | La contraseña de esa cuenta | El usuario de Drupal |
| Craft CMS | Token de GraphQL de Craft | No |
| Concrete CMS | Secreto de cliente | ID de cliente |
| Ghost | Clave de Admin API | No |
| Webflow | Token de API de Webflow | No |
| Wix | Clave de API de Wix | El ID de tu sitio de Wix |
| Contentful | Token de gestión de contenido | No |
| Strapi | Token de API de Strapi | No |
| Sanity | Token de API de Sanity | No |
Leído del formulario de conexión de cada adaptador, así que esta tabla y el formulario que rellenas de verdad no pueden contradecirse.
La mejor de todas, y por qué
Concrete CMS, y no está ni cerca, que es una frase sorprendente sobre la plataforma que menos trabajos de nuestra lista permite. Concrete se conecta mandándote a tu propia web a aprobar una integración, y el acceso que sale de ahí queda atado a tu cuenta. Ninguna contraseña sale de tus manos, y lo revocas desde tu propio panel en vez de pedírnoslo a nosotros.
Hay una lección en cómo lo descubrimos. Concrete ofrece también la conexión con credenciales que usan todas las demás plataformas de aquí, y funciona: el token se emite, va firmado y lee la web perfectamente. Después falla toda escritura, porque Concrete ata los permisos a una persona y ese tipo de token no lleva ninguna. El arreglo que habríamos elegido por comodidad era el que no podía funcionar, y el que funciona es el que habríamos elegido por principios. WordPress es el segundo con sus contraseñas de aplicación, y después viene un campo de claves que se diferencian sobre todo en si se pueden limitar.
Tres arreglos con los que hay que tener cuidado
No es una crítica a las plataformas: cada uno de estos es una decisión razonable de alguien con otras limitaciones. Pero cada uno te pide algo que los demás no.
- La autenticación básica de Drupal usa la contraseña real de una cuenta. En el núcleo no hay equivalente a una contraseña de aplicación, así que la credencial es el acceso de verdad de una cuenta. La única forma segura de usarla es crear una cuenta para este trabajo, con un rol que pueda editar contenido y poco más, que es lo que dice nuestra página de configuración en el paso anterior a pedírtela.
- Una clave de Wix llega a todas las webs de la cuenta. Se crea a nivel de cuenta, y a qué web va a parar una petición lo decide la petición y no la clave. Eso tiene una consecuencia directa que tuvimos que rodear: una clave de Wix no demuestra nada sobre ser dueño de una web concreta, así que una web de Wix se verifica como cualquier otra, con un archivo o una etiqueta meta. El token de Webflow llega exactamente a una web, y por eso ese no necesita ninguna prueba aparte. Dos plataformas alojadas, respuestas opuestas, y la diferencia está en qué demuestra la credencial.
- Los permisos de una clave de Wix no se cambian después de crearla, y un token de Contentful se puede crear en un estado que no sirve para nada. Wix: si marcas mal las casillas, el remedio es una clave nueva. Contentful: un token personal de gestión hay que autorizarlo después contra tu organización, y hasta que no lo haces ve tu cuenta y ninguno de tus espacios, que es exactamente igual que un token equivocado.
Qué pasa con ella después de que la pegues
Conviene decirlo claro, ya que toda la entrada va de no tener que fiarse de nadie. Cada credencial se guarda cifrada, y cada una queda atada a la web a la que pertenece: un secreto guardado que se copiara del registro de una web al de otra no se puede descifrar, en vez de autorizar en silencio a la web equivocada. La clave que hace ese cifrado vive fuera de la carpeta pública y no está nunca en el código. Al registro no se escribe nunca nada: ni una credencial, ni una cabecera de autorización, ni el cuerpo de una petición de token. Y cuando desconectas una web, el secreto guardado se va con ella, que es la mitad fácil; la mitad importante es que también puedes revocarlo en el otro extremo, en tu propia plataforma, sin pedirnos nada.
Límite honesto: una credencial que guardamos nosotros sigue siendo una credencial que tiene otro, por bien cifrada que esté, y el único arreglo que evita eso del todo es el de tipo Concrete, donde apruebas el acceso en tu propia web. De 11 plataformas, una lo ofrece. Preferimos nombrar ese hueco por lo que es antes que describir el cifrado como si fuera lo mismo.
Lo que nos preguntan sobre esto
- ¿Qué es más seguro, una clave de API u OAuth?
- OAuth, claramente: ninguna contraseña sale de tus manos, el acceso queda atado a tus propios permisos y lo retiras desde tu propio panel. Una clave de API limitada es un segundo puesto razonable. La que hay que evitar es la clave sin límites que vale por un administrador.
- ¿Una contraseña de aplicación es la misma que mi contraseña de WordPress?
- No, y en eso consiste. Es una credencial aparte, hecha para una aplicación, que solo sirve para la API REST. Borrarla no cambia nada de cómo entras tú, y nunca revela tu contraseña de verdad.
- ¿Y si quiero quitar el acceso ahora mismo?
- Hazlo en tu lado, en tu propia plataforma: borra la contraseña de aplicación, revoca el token o quita la integración. Eso funciona hagamos lo que hagamos nosotros, que es justo por lo que es mejor respuesta que pedírnoslo.