Skip to main content
Con el inicio de sesión único SAML su institución tiene una API key en lugar de una key por médico. Su proveedor de identidad (Okta, Azure AD, ADFS…) autentica al médico, y su backend intercambia la key de la institución más una aserción SAML firmada por un token de sesión del médico. Todos los endpoints de negocio siguen iguales — solo cambia el valor de Authorization.

Cómo funciona

  1. Su IdP autentica al médico y firma una aserción SAML.
  2. Su backend llama POST /v1/sso/exchange con la secret key de su institución y la aserción.
  3. Telepatia verifica la firma, el emisor, la audiencia y la validez contra la configuración SAML de su institución, y devuelve un access token del médico más un refresh token.
  4. Su backend llama la API con el token del médico y lo renueva con POST /v1/sso/refresh — sin nueva ida al IdP hasta que la cadena de refresh termina.

Requisitos previos

  • Una secret key de institución (sk_…) creada con el permiso SAML SSO exchange (la casilla saml:exchange en la página de API Keys de la plataforma).
  • La configuración SAML guardada en la pestaña Developers → SSO de la plataforma: el entity ID (emisor) de su IdP y su certificado de firma.
  • El médico ya debe existir en su institución. El SSO autentica médicos; no los crea.

Datos del Service Provider

Registre estos valores fijos de Telepatia en su proveedor de identidad. Son los mismos para todas las instituciones.

Intercambiar una aserción

Envíe la respuesta SAML codificada en base64 con la key de su institución:
Respuesta 200:
Guarde la sesión y reutilícela hasta que expire. Cada aserción es de un solo uso — un segundo intercambio con la misma aserción devuelve 403.

Requisitos de la aserción

  • La aserción está firmada (RSA-SHA256, firma envuelta) con el certificado configurado para su institución.
  • El Issuer es igual al entity ID del IdP configurado para su institución.
  • El Audience es igual al SP entity ID de arriba.
  • El Destination es igual a la ACS URL de arriba.
  • La ventana de validez (NotBefore / NotOnOrAfter) cubre el momento del intercambio.
  • La aserción incluye un AttributeStatement — los IdP estándar siempre lo incluyen.
  • El email del médico llega como NameID del sujeto (formato emailAddress), o en el atributo indicado por el ajuste opcional email attribute.

Renovar la sesión

El refresh token es la credencial — sin key de institución y sin aserción:
La respuesta trae la misma forma de sesión que el intercambio. Los refresh tokens rotan: el anterior se revoca cuando se emite el par nuevo, y reutilizarlo devuelve 401.

Llamar la API como el médico

Use el access token exactamente donde iría la API key:

Respuestas de error

Ejemplo: aserción reutilizada

Ejemplo: aserción inválida