Esta sección documenta el IdP de B Brands — la plataforma de autenticación
centralizada expuesta a través de
auth.bbrands.io. Es el único lugar donde el
holding demuestra quién es un usuario y si está habilitado para una
plataforma dada (ERP, CRM, analytics, futuros SaaS, partners).Qué es esto
El IdP de B Brands es el proveedor de identidad estándar del holding. Cualquier plataforma — existente o futura — autentica a sus usuarios vía OAuth 2.1 / OpenID Connect contra B Brands, en lugar de mantener su propia base de datos de usuarios. El protocolo lo maneja un motor OAuth 2.1 / OIDC administrado, envuelto por completo detrás del origenauth.* por entorno. Los clientes nunca ven el
motor subyacente: el registro de clientes, el ciclo de vida de la identidad, la auditoría y cada
endpoint público viven en la capa de identidad de B Brands. El motor es un
detalle de implementación reemplazable.
La regla de oro: el IdP autentica, no autoriza
Este es el concepto más importante para cada equipo que se integra con el IdP. Tenlo presente mientras lees el resto de la sección.Lo que el IdP hace
Demuestra la identidad de un usuario (
sub, email, perfil), entrega
su contexto de cuenta de negocio (https://bbrands.io/profile: cuenta
primaria y su id de sistema externo) y si está habilitado para una
plataforma (active / suspended / revoked).Lo que el IdP NO hace
No gestiona los permisos de las aplicaciones. Cada aplicación cliente decide
qué puede hacer un usuario dentro de ella. No existe un catálogo central de permisos.
1
Un usuario inicia sesión en una app cliente vía B Brands
El IdP solo autentica. La app cliente autoriza a sus propios usuarios con sus
propios roles/grupos.
2
Una app cliente consume las APIs de B Brands
B Brands protege sus propios datos con el RBAC interno existente. El cliente
actúa con un JWT interno de B Brands obtenido a través del
intercambio de tokens (contexto de usuario) o con una
API key existente (máquina a máquina, sin usuario).
Dos formatos de token coexisten
Los dos nunca se mezclan: ES256 para la identidad hacia los clientes, HS256 para consumir
las APIs de B Brands. Consulta Seguridad para el modelo de tokens completo.
Quién debería leer qué
Integradores (nueva plataforma)
Configura tu cliente OAuth, el discovery, las redirect URIs y (opcionalmente) el
intercambio de tokens para llamar a las APIs de B Brands.
Backend / arquitectos
Las capas de componentes, el facade del motor, los ADRs y el hook de token de acceso.
Backend / integradores
El contrato de los endpoints OAuth / OIDC: discovery, authorize, token, userinfo,
revoke.
Seguridad / compliance
Modelo de tokens, gestión de secretos, modelo de amenazas, niveles de revocación y auditoría.
Datos / ciclo de vida
Las entidades de identidad, el ciclo de vida de habilitación y el kill switch.
Equipos de frontend
El inicio de sesión social para usuarios finales, separado, a través del motor administrado.
Entornos
El IdP se ejecuta en múltiples entornos. Cada uno tiene su propio motor aislado, su propio issuer y sus propios clientes OAuth registrados. Un token acuñado en un entorno nunca es válido en otro, porque los clientes validan eliss de su propio
entorno.
Cada superficie OAuth/OIDC — discovery, JWKS, authorize, token, userinfo, revoke
y la UI interactiva de consentimiento/login — vive bajo el mismo origen
auth.* por entorno. Ese origen es el issuer canónico incrustado en cada token
emitido.
Un único origen de identidad de cara al usuario, a propósito:
auth.* es el
issuer canónico y sirve cada endpoint del protocolo más la UI de consentimiento
(con la misma forma que accounts.google.com). El dominio api.* aloja la
implementación subyacente y las APIs de negocio de B Brands, pero no es
el issuer anunciado — los clientes solo configuran auth.*. Consulta
Arquitectura para el registro de decisiones.Convención de nombres de clientes
Los identificadores de cliente OAuth siguen el patrón<platform>-<environment>, p. ej.
erp-prod, erp-cert, erp-dev. Registra siempre un cliente distinto por
entorno.