Ajustes del Gateway

Configuración a nivel workspace de todo lo que el gateway hace en nombre de tus usuarios finales: si tienen que confirmar su correo, dónde caen después de loguearse, cómo se ven las páginas de login alojadas, y qué campos extra llevan sus cuentas.

Lo encontrás en API Gateway → Settings.

Confirmación de correo

Con la confirmación apagada, una cuenta puede loguearse apenas se registra y emailVerified solo registra si alguna vez hizo clic en el enlace. Con ella encendida, el gateway bloquea el login hasta que lo haga.

Apagada es el default correcto para la mayoría de los productos: le saca un paso a tu embudo, y tu app igual puede condicionar lo que importe a emailVerified. Encendela cuando una cuenta sin verificar pueda hacer algo que preferirías que no — gastar crédito, escribirle a otros usuarios, aparecer en un directorio.

Los correos de confirmación necesitan un proveedor de correo configurado en el workspace. Sin uno, encender esto deja afuera a toda cuenta nueva, porque el correo que las desbloquea nunca se manda.

El redirect post-login, y cómo cruza la identidad

Es el ajuste más útil de la página y el menos obvio.

Definí una URL de redirección post-login y el gateway manda al usuario ahí después de un login exitoso, con un token firmado en el query string:

https://app.example.com/dashboard?redirect_token=<jwt_firmado>

Ese token se firma con RS256 usando un par de claves propio de tu workspace. Tu app lo verifica contra la clave pública del workspace, publicada como JWKS:

GET https://api.praxsuite.com/api/v1/gateway/{workspaceId}/auth/jwks.json

import { createRemoteJWKSet, jwtVerify } from "jose";

const JWKS = createRemoteJWKSet(
  new URL(`https://api.praxsuite.com/api/v1/gateway/${WORKSPACE}/auth/jwks.json`)
);

const { payload } = await jwtVerify(redirectToken, JWKS, {
  issuer: "praxsuite-gateway",
  maxTokenAge: "60s",
});

payload.sub;        // el id del usuario final
payload.email;      // su correo
payload.workspace;  // el id del workspace
payload.jti;        // tratalo como de un solo uso

Tres propiedades hacen que valga la pena esto en vez de pasarte una sesión vos mismo:

• Verificación por clave pública. Tu app nunca sostiene un secreto compartido. Rotar el par de claves no implica volver a desplegar tu app.

• De vida corta. Verificá con una antigüedad máxima de unos 60 segundos — el token existe para cruzar un redirect, no para ser una sesión.

• De un solo uso por convención. Guardá los jti vistos por ~65 segundos y rechazá repetidos. El token va en una URL, y las URLs terminan en el historial, en logs y en referrers.

Así se entrega una identidad ya autenticada desde la página de login alojada de Praxsuite hacia tu propia aplicación, sin que ninguno de los dos lados tenga que confiar en el almacenamiento del otro.

Las páginas de login alojadas

Praxsuite sirve pantallas listas de registro, login y reset de contraseña en:

https://portal.praxsuite.com/public/workspace/{workspaceId}/auth/login

Si tu producto solo necesita que los usuarios se autentiquen, ya existen, y esta sección es cómo las hacés tuyas.

Cada campo de registro que habilitás es un campo que alguien tiene que llenar antes de poder empezar. Habilitá los que realmente vayas a usar.

Los proveedores sociales de acá son los botones de la página alojada; un proveedor OIDC completo (un directorio corporativo, tu propio servidor de identidad) se configura aparte y está descrito en Autenticación.

Campos personalizados de usuario final

Tus usuarios finales necesitan atributos sobre los que Praxsuite no tiene opinión — el nombre de la empresa, un nivel de plan, una sucursal preferida. Definilos acá, y cada uno recibe una clave, un nombre visible y un tipo de dato.

Los valores viven en el objeto settings de cada usuario final, indexados por la clave de la definición:

{
  "email": "ana.rojas@example.com",
  "settings": {
    "companyName": "BlueWave",
    "plan": "pro"
  }
}

La definición es el esquema y la cuenta guarda los valores — así que agregar un campo no obliga a tocar las cuentas existentes, y quitar uno no pierde lo que ya estaba guardado.

De dónde sale la URL pública

Settings también lleva gatewayPublicUrl, el host que deberían usar los llamadores de tu workspace. Todo lo del portal que te muestra una URL — la barra del Playground, la cadena de conexión del Event Bus, la dirección de un endpoint — la lee de acá.

Eso importa en un despliegue dedicado, donde el host no es gateway.praxsuite.com. Copiá las URLs del portal en vez de armarlas a mano y van a estar bien en todos los tiers.

Siguiente

• Usuarios Finales — las cuentas que gobiernan estos ajustes.

• Autenticación — los endpoints detrás de las páginas alojadas.