Autenticación y autorización¶

Polyguard utiliza diferentes mecanismos de autenticación dependiendo de si la persona que llama es un dispositivo móvil, una aplicación web o un cliente API del lado del servidor. Esta página cubre los tres.

SDK móvil: certificación de hardware¶

Toda la comunicación entre el SDK móvil y las API de Polyguard se basa en una certificación de hardware: prueba criptográfica de que la solicitud se origina en un dispositivo genuino y no comprometido que ejecuta una copia legítima de la aplicación.

API REST: tokens de sesión¶

Las llamadas API del lado del servidor y basadas en web para la administración de enlaces, el acceso a registros y la administración de usuarios requieren un token de sesión activo en el encabezado Authorization.

Authorization: Bearer <session_token>

Obtener un token de sesión¶

Existen dos métodos para obtener un token de sesión:

Método 1: intercambio JWT¶

Si tiene un Polyguard JWT existente para un PolyUser con una cuenta de usuario, puede cambiarlo por un token de sesión.

POST /api/v1/auth/token
{
  "grant_type": "jwt_exchange",
  "jwt": "<polyguard_jwt>"
}

La respuesta incluye un token de sesión y su tiempo de vencimiento:

{
  "session_token": "pg_sess_...",
  "expires_at": "2026-02-24T12:00:00Z"
}

Método 2: intercambio de tokens SSO¶

Si su organización utiliza un proveedor de SSO integrado, puede intercambiar un token de acceso de ese proveedor por un token de sesión de Polyguard.

POST /api/v1/auth/token
{
  "grant_type": "sso_exchange",
  "provider": "microsoft_entra",
  "access_token": "<sso_access_token>"
}

El formato de respuesta es el mismo que el del intercambio JWT.

Integración SSO¶

Polyguard admite el inicio de sesión único federado para operadores de plataforma y usuarios comerciales que desean autenticar a sus usuarios a través de su proveedor de identidad existente.

Proveedores compatibles¶

Cómo funciona¶

1. El usuario se autentica con el proveedor de SSO de su organización (por ejemplo, Microsoft Entra ID).
2. Su aplicación recibe un token de acceso del proveedor de SSO.
3. Su aplicación intercambia ese token de acceso por un token de sesión de Polyguard a través del punto final /auth/token.
4. Las llamadas posteriores a la API de Polyguard utilizan el token de sesión de Polyguard.

Esto significa que sus usuarios nunca necesitarán credenciales de Polyguard separadas: se autentican con su identidad organizacional existente y Polyguard asigna esa identidad a la cuenta de usuario y los permisos apropiados.

Mapeo de roles¶

Cuando se configura SSO, Polyguard puede asignar grupos o reclamos de SSO a roles de cuentas de usuario dentro del modelo de objetos de Polyguard. Esto le permite controlar qué usuarios de su organización pueden crear vínculos, acceder a registros de auditoría o administrar la configuración de la aplicación, todo ello en función de sus membresías en grupos SSO existentes.

Autenticación del SDK web¶

El SDK web en sí no requiere autenticación separada para mostrar el modo de verificación de confianza. El SDK se inicializa con una URL de enlace (obtenida a través de la API REST durante la fase de preparación) y la sesión de verificación de confianza se autentica a través del propio token del enlace.

const polyguard = new Polyguard({ appId: "your-app-id" });

// The link URL contains embedded session authentication
polyguard.startTrustCheck({ linkUrl: "https://api-global.polyguard.ai/link/..." });

Las llamadas API de backend que crean el enlace y recuperan resultados aún requieren un token de sesión, como se describe anteriormente.

Resumen¶