> ## Documentation Index > Fetch the complete documentation index at: https://docs.hi-doctor.ai/llms.txt > Use this file to discover all available pages before exploring further. # Seguridad del conector > Cómo autentica el conector a los pacientes, qué almacena y qué se niega deliberadamente a hacer. El servidor MCP de Hi-Doctor es un **servidor de recursos** OAuth 2.1. No tiene base de datos de pacientes propia: cada llamada a una herramienta se reenvía a la API de Hi-Doctor actuando como *usted*, con los permisos de su propia cuenta. ## Inicio de sesión La conexión sigue un flujo estándar de código de autorización de OAuth 2.1 con **PKCE** (`S256`). Su cliente de IA nunca ve su contraseña: usted la introduce en una página de Hi-Doctor y el cliente recibe un código de autorización de vida corta que canjea por un token. El servidor publica los documentos de descubrimiento que espera un cliente MCP, de modo que no hace falta ninguna configuración manual: | Documento | Estándar | | ----------------------------------------- | --------------------------------------- | | `/.well-known/oauth-protected-resource` | RFC 9728 | | `/.well-known/oauth-authorization-server` | RFC 8414 | | `POST /register` | RFC 7591, registro dinámico de clientes | Los códigos de autorización son de **un solo uso** y de vida corta. Canjear uno dos veces falla: un código reutilizado se rechaza, no se acepta. ## A dónde puede devolverse un token A cada cliente registrado se le emite un `client_id` firmado que **vincula la URI de redirección exacta** con la que se registró. En el momento de la autorización, la `redirect_uri` solicitada debe coincidir exactamente con esa vinculación. Esta es la defensa frente a la interceptación del código de autorización: un atacante que conozca su `client_id` sigue sin poder pedir que el código se entregue en su propio servidor, porque la URI va sellada dentro del identificador y se verifica antes incluso de mostrar el formulario de inicio de sesión. Las redirecciones de bucle local (*loopback*) siguen el RFC 8252 §7.3: el puerto puede variar, como necesitan los clientes de escritorio, pero el resto de la URI debe coincidir. ## Tokens Los tokens de acceso son **sobres cifrados con AES-256-GCM**, no credenciales del backend en claro. Cada sobre está vinculado a su destinatario y se rechaza si se manipula, si se reutiliza contra el recurso equivocado o si se presenta después de que haya caducado el token de backend que envuelve. Un sobre de refresco no puede usarse donde se exige un sobre de acceso. Su contraseña de Hi-Doctor se canjea por un token al iniciar sesión y el conector nunca la almacena, nunca la escribe en un registro y nunca se la pasa a la aplicación que se conecta. ## Permisos Las herramientas están agrupadas y cada grupo exige su propio ámbito: perfil, consultas, mensajes, cuestionarios, evolución y pago. Una herramienta cuyo ámbito no haya concedido no solo se rechaza, sino que **no se ofrece**: nunca aparece en la lista de herramientas del cliente. Los roles no se acumulan. Cada cuenta tiene exactamente un catálogo de herramientas, así que un token de paciente nunca puede alcanzar una herramienta clínica o de administración. Consulte [Permisos](/es/mcp/permissions) para la lista completa de concesiones. ## Qué se niega a filtrar el servidor * **Los cuerpos de las respuestas `5xx` del backend se descartan por completo.** Un error del servicio subyacente devuelve un fallo genérico y estable, no una traza interna. * **Las respuestas `4xx` se filtran contra una lista blanca** de campos estructurados, de modo que un error puede ser útil sin devolver datos del paciente en el resultado de la herramienta. * Los argumentos de ruta no pueden salir del host de la API configurado ni de su prefijo de versión. * La limitación de peticiones se aplica por token, no por una cabecera que quien llama pudiera modificar para conseguir un cupo nuevo. ## Pago El conector nunca maneja datos de tarjetas. `hidoctor_checkout_create` devuelve un enlace al proceso de pago alojado por Stripe, y los cambios de tarjeta, plan y dirección de facturación se hacen en el portal de facturación de Stripe. No existe ninguna herramienta que acepte un número de tarjeta, y cualquier asistente que le pida uno no está hablando con Hi-Doctor. ## Límites clínicos Ningún token, de ningún tipo, puede aprobar una consulta, emitir o modificar una receta ni cambiar una dosis. Esas acciones no las expone el servidor MCP en absoluto: no están detrás de un ámbito, sencillamente no existen. La idoneidad médica la impone el backend de Hi-Doctor al enviarse un cuestionario. Un asistente no puede aprobar a un paciente de antemano, y volver a enviarlo con respuestas distintas no salta la comprobación. ## Notificar un problema Escriba a [hello@hi-doctor.ai](mailto:hello@hi-doctor.ai) con los detalles. Si cree que hay datos de pacientes expuestos, indíquelo en el asunto para que se priorice.