--- title: Tokens, OAuth y passkeys description: Quién puede llegar a tu Hollware, con qué, y las protecciones delante de cada solicitud. section: concepts order: 3 --- # Tokens, OAuth y passkeys ## Tres tipos de tokens | Token | Empieza con | Llega a | Se crea con | | ------------ | ----------- | ------------------------------- | ---------------------------------- | | Personal | `hw_pat_` | MCP, la API de lectura, las operaciones por HTTP | `hollware token create`, el admin | | De lectura | `hw_read_` | solo la API de lectura, contenido publicado | `hollware token create --read` | | De acceso OAuth | (opaco) | lo que la persona permitió | un cliente OAuth y una página de consentimiento | Hollware guarda el SHA-256 de un token, nunca el token, y muestra uno nuevo una sola vez. Un token es de un sitio, vence después de los días que le indiques (de 1 a 365), o nunca si no indicas ninguno, y se puede revocar desde la CLI o el admin; un token revocado deja de funcionar en la siguiente solicitud. Un token vale lo que vale hoy su persona: en cada solicitud, sus scopes se intersecan con el rol actual de la persona. ## Passkeys Las personas inician sesión solo con passkeys. El primer dueño configura una con el enlace que imprime `hollware init`; los demás, con una invitación. En **Tu cuenta**, cada persona les pone nombre a sus passkeys y elimina una que perdió, nunca la última; y cambia su propio nombre, que nadie más puede cambiar. El admin es un cliente OAuth del propio Hollware, y guarda su token de acceso solo en memoria. ## Secretos Los envíos de un webhook se firman con un secreto que crea Hollware (`make_webhook_secret`, o **Sitio** en el admin), que se muestra una sola vez y se guarda en la base de datos sellado con AES-GCM bajo el secreto del Worker `HOLLWARE_SECRET`, así que la base de datos sola nunca guarda uno en claro. `hollware deploy` crea `HOLLWARE_SECRET` cuando el Worker no lo tiene, y nunca reemplaza uno que ya existe: uno nuevo dejaría los secretos sellados sin poder abrirse, y los webhooks necesitarían secretos nuevos. Cambiar la estructura de un sitio requiere `schema:admin`, que solo otorga el rol de dueño, tenga quien tenga el token: una persona en el admin o un agente. ## Protecciones - **Host y Origin.** Hollware responde solo a las solicitudes para el host de `HOLLWARE_PUBLIC_URL`. Una solicitud desde una página de otro origen se rechaza, salvo las lecturas de la API de lectura desde los orígenes que un sitio lista en `cors.origins`. - **Sin cookies en las APIs.** `/mcp` y `/v1` leen el encabezado `Authorization` y nada más. La cookie de sesión de una persona solo la leen las páginas de inicio de sesión. - **Sin indexación.** Cada respuesta lleva `X-Robots-Tag: noindex, nofollow` y `/robots.txt` lo prohíbe todo: el admin, las APIs y las imágenes no son para buscadores. Tus sitios sí. - **Imágenes que no ejecutan nada.** Un SVG se acepta solo cuando nada en él se ejecuta ni sale del archivo, y se sirve con una política que no ejecuta nada (ver [Imágenes](/docs/images/#svg)). - **Metadatos de clientes por internet pública.** El servidor OAuth obtiene los documentos de metadatos de los clientes con `global_fetch_strictly_public`, así que un cliente no puede hacer que apunte a tu propia red. ## Registro de actividad Cada cambio de un sitio y cada rechazo queda como una línea en su registro de actividad: quién lo hizo, tal como Hollware lo verificó (una persona en el admin, un token personal, una app que una persona autorizó, o Hollware mismo al publicar lo programado), lo que el cliente dijo de sí mismo (su cliente MCP y su modelo, que se muestran aparte porque es lo que el cliente declara), la acción, sobre qué actuó y cómo terminó: realizada, denegada por falta de un permiso, o fallida. Incluye cada operación que no es de lectura, los tokens creados y revocados, los roles, los miembros quitados, las invitaciones creadas y aceptadas, el inicio y el cierre de sesión, las passkeys renombradas y quitadas, los nombres cambiados, las apps autorizadas y revocadas, y las publicaciones programadas. Las lecturas no se registran. El registro solo admite agregar líneas: ninguna se modifica, y ninguna se borra antes de que se cumpla la retención de su sitio. Los dueños lo leen en el admin, en **Actividad**, lo filtran por acción, persona y fechas, y lo descargan como CSV. El dueño decide qué guarda, en **Sitio**, **Registro de actividad**: - **Direcciones IP:** no se guardan por defecto. Una dirección es un dato personal; si decides guardarlas, Hollware guarda solo un hash de cada dirección con una clave propia del sitio, nunca la dirección, de modo que se puede saber que varias solicitudes vinieron de la misma dirección sin poder saber cuál es. - **Retención:** indefinida por defecto, o de 30 a 3650 días, tras los cuales Hollware borra las líneas. `hollware init` y `npm create hollware` aceptan las mismas opciones como `--ip-addresses hashed` y `--audit-retention-days 365`. ## Reporta una vulnerabilidad Repórtala en privado por los avisos de seguridad del repositorio de GitHub, nunca en un issue.