Atar el ecosistema a un IdP de terceros no era una opción.
“Cada componente nuevo cableado contra Auth0 multiplica vendor lockin: pricing por MAU, claims no controlados, ciclo de release ajeno. Para un ecosistema multi-componente B2B la autenticación es infraestructura propia, no un proveedor más.”
Vendor lockin
Cambios de pricing, SLA o política del IdP externo se propagan al instante a N componentes. Cero margen de negociación.
Claims ajenos
Los `claims` del JWT los define el IdP — no el ecosistema. `tenant_id` y `tenant_slug` quedan como custom claims frágiles.
Costo por usuario
Auth0 cobra desde US$23 por mil MAU activos. En multi-tenant B2B regional ese costo escala antes que el revenue del componente.
1Qué hace BMonkey.
BMonkey resuelve la autenticación del ecosistema: verifica quién es el sujeto que entra y emite un JWT canónico. La autorización (roles, permisos, qué puede hacer ese sujeto) sigue siendo de cada componente — BMonkey no se mete ahí. Frontera dura.
AuthN centralizada
Un solo lugar donde se verifica credenciales del usuario. Cada componente del ecosistema delega esa verificación.
- OAuth 2.0 + OpenID Connect estándar
- JWT firmado RS256 con JWKS expuesto
- PKCE obligatorio en authorization code flow
AuthZ por componente
Cada producto BJungle define sus propios roles, permisos y políticas multi-tenant. BMonkey no opina sobre eso.
- RBAC interno por componente
- Políticas multi-tenant locales
- Audit de acciones en cada producto
Claims canónicos
Todo JWT incluye <code>tenant_id</code> y <code>tenant_slug</code> del ecosistema BJungle. Los componentes filtran RLS sobre ese claim.
- <code>sub</code> · UUID inmutable del usuario
- <code>tenant_id</code> · scope organizacional
- <code>email_verified</code> · estado de la cuenta
2IdP propio, no proveedor más.
Auth0, Cognito y Keycloak son IdPs sólidos para una app aislada. Para un ecosistema multi-componente B2B, atar la autenticación a un vendor externo multiplica fricción operativa y comercial.
Control
Claims canónicos propios
<code>tenant_id</code> y <code>tenant_slug</code> son ciudadanos de primera clase, no custom claims frágiles que dependen del UI del IdP externo.
Independencia
Anti vendor lockin
Cambios de pricing, SLA o política del IdP externo no se propagan a N componentes. La evolución la decide el ecosistema.
Costo
Sin costo por usuario
Auth0 cobra >US$23 por mil MAU activos. En multi-tenant B2B regional ese costo escala antes que el revenue del componente.
Multi-component
Un client_id por producto
BRhino, BLeopard, BGorilla, BPanther… cada uno tiene su client_id propio. Sin friction de gestión cross-tenant en consola ajena.
3Estándar abierto, no SDK propietario.
BMonkey expone OIDC discovery + JWKS. Cualquier componente que entienda OpenID Connect lo consume sin SDK propietario. Integrarlo en un componente nuevo lleva las horas de cualquier integración OIDC.
Discovery
OIDC discovery URL
Endpoint público con metadata del IdP: endpoints, scopes soportados, algoritmos de firma. Cliente OIDC estándar lo consume sin código custom.
Firma
JWKS · JWT RS256
Keys públicas expuestas vía JWKS. Verificación de tokens local en cada componente. Sin round-trip a BMonkey por request.
Flow
Authorization Code + PKCE
Flow estándar OAuth 2.0 con PKCE obligatorio. SPA, mobile y backend usan el mismo patrón seguro por defecto.
4Un BMonkey · N componentes · M tenants.
Cada cliente B2B final del ecosistema tiene su tenant en BMonkey. Cada producto BJungle es un client_id distinto. Un solo BMonkey sirve a N componentes y M tenants sin duplicar infra ni mezclar contextos.
tenant_id del sujeto. Sobre ese claim filtra RLS, valida policies y resuelve scope. Cero código de tenant-routing en cada producto.5Cuatro líneas duras que separan B2B de B2C.
BMonkey es B2B y vive en bjungle.net. Lo que era OnlyOne queda diferido a NewCo B2C en sitio separado. La separación no es de UX — es de estrategia.
BMonkey · B2B
IdP corporativo del ecosistema BJungle. Cada cliente B2B (banco, cooperativa, caja, aseguradora) tiene su tenant. Vive en bjungle.net.
OnlyOne · B2C (diferido)
Wallet de identidad consumer-facing del usuario final. Se reactiva cuando se levante NewCo. Vivirá en sitio separado — no en bjungle.net.
Sin narrativas mezcladas
BMonkey no habla de wallet personal, identidad portable del consumidor ni SSI. Esa línea es exclusivamente de la conversación B2C de NewCo.
Sin colisión técnica
BMonkey emite JWT corporativos. OnlyOne emitirá Verifiable Credentials W3C consumer-facing. Estándares distintos, audiencias distintas.
6V1 → V2 → V3 sin fechas duras.
OAuth 2.0 + OpenID Connect core. Multi-tenant nativo. JWT RS256 con JWKS expuesto. Claims canónicos del ecosistema (tenant_id + tenant_slug). Punto de entrada para todos los componentes B2B.
MFA configurable por tenant. SSO empresarial vía SAML bridge para clientes con AD/Entra ID. Soporte de IdP federados (Google Workspace, Azure AD) cuando el cliente final lo exija.
Eventos críticos de AuthN (login admin, token revocation, cambio de credencial) sellados en Polygon vía BLion. Step-up auth contextual basado en señal de riesgo del componente.
7Lo que más nos preguntan.
¿BMonkey reemplaza a Auth0 / Cognito / Keycloak en mi institución?
¿Qué cobra BMonkey por usuario?
¿Cumple con LPDP / GDPR?
¿Puedo federar contra mi Azure AD / Google Workspace?
¿Y la autorización (roles, permisos)?
¿Qué pasa con la decisión OnlyOne previa?
8Todo el ecosistema B2B habla con BMonkey.
Cada componente del ecosistema BJungle autentica vía BMonkey. La autorización vive en cada producto. El JWT canónico viaja sellado entre componentes — y en V3, los eventos críticos también van a blockchain.
BMonkey es infraestructura del ecosistema, no producto standalone.
BMonkey no se demuestra como producto individual — se entiende mirando el ecosistema completo. Si la conversación es identidad B2B en LATAM, hablemos.