Skip to main content
Esta página cubre dos sistemas que son diferentes del IdP OAuth para clientes externos. No los confundas:

1. Inicio de sesión social

Los usuarios finales inician sesión en las apps de B Brands con un proveedor social. Esto usa el inicio de sesión social del motor administrado directamente, luego acuña el JWT interno de B Brands — no usa el IdP OAuth, los tokens ES256, ni la pantalla de consentimiento.

Rutas

  • La ruta de inicio requiere redirect_url; format=json (o Accept: application/json) devuelve JSON en lugar de un 302.
  • La página /callback es un puente HTML que lee el fragmento de la URL (#access_token…) o ?code= y lo reenvía a /callback-redirect.
  • /callback-redirect establece la sesión del motor, autorregistra un perfil si es necesario, y devuelve el JWT interno de B Brands (HS256) más los datos de la cuenta.
Existen rutas heredadas para proveedores adicionales bajo una versión anterior de la API. El flujo actual añade un redirect_url parametrizable y soporte JSON/deep-link.

2. SSO interno — el handshake entre apps

Cuando un usuario inicia sesión vía la app de autenticación y debe aterrizar en una app hermana de B Brands en un dominio diferente, la sesión se transporta con un token firmado de vida corta en la URL. Un pequeño paquete interno compartido maneja esto.

Paquete interno compartido de SSO

Un pequeño paquete para las apps consumidoras, con helpers para:

El emisor del SSO

La app de autenticación es la UI centralizada de login/registro/2FA + consentimiento. Es el emisor: firma el token de handshake y escribe la cookie de sesión directamente en server actions (no monta el proxy consumidor). Los targets del mismo dominio redirigen sin token de handshake; los targets de dominio cruzado reciben uno.
El exchange de SSO interno (/api/v3/auth/sso/exchange) es para la transferencia de sesión entre apps. No es el exchange de clientes OAuth externos (/api/v3/oauth/exchange). Consulta Intercambio de tokens.

Modelo de seguridad