BJungle
BMonkey

CORE de identidad del ecosistema

Identidad del ecosistema conestándar abierto.

  • CORE · CAPA 01Pieza estructural del ecosistema BJungle
  • OPENID CONNECTDiscovery + JWKS contra estándar abierto
  • MULTI-TENANTClaims canónicos tenant_id + tenant_slug
  • SIN PROVEEDORProtocolo abierto sin terceros sobre el ecosistema
Por qué CORE propio

Atar el ecosistema a un IdP de terceros no era una opción arquitectónica.

“Cada componente nuevo cableado contra un IdP externo multiplica dependencia: claims no controlados, ciclo de release ajeno, política de identidad heredada. Para un ecosistema multi-componente B2B la autenticación es pieza estructural, no un proveedor más.”

Decisión Javier + Jonhjar · 2026-06-14 · sesión Estrategia BJungle.

Riesgo 01

Dependencia operativa

Cambios de SLA, política o lifecycle del IdP externo se propagan al instante a N componentes del ecosistema. Cero margen de decisión.

Riesgo 02

Claims ajenos

Los <code>claims</code> del JWT los define el IdP — no el ecosistema. <code>tenant_id</code> y <code>tenant_slug</code> quedan como custom claims frágiles.

Riesgo 03

Política de identidad

Quién es un usuario válido, qué factores se exigen y cuándo se revoca una sesión lo define el vendor. El ecosistema hereda esas reglas sin participar de su diseño.

Funcional

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
BMonkey verifica quién entra. No verifica qué puede hacer. La autorización pertenece a cada componente — esa frontera es la decisión raíz del ecosistema (SPEC-AUTH-ECOSISTEMA-BJUNGLE.md §1).
Por qué CORE y no Auth0 / Cognito

2CORE 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 significa heredar su lifecycle, su política y su forma de modelar identidad. Acá el modelo lo decide el ecosistema.

Control

Claims canónicos propios

<code>tenant_id</code> y <code>tenant_slug</code> son ciudadanos de primera clase, no custom claims frágiles atados al UI del IdP externo.

Independencia

Lifecycle del ecosistema

Versiones, breaking changes y deprecaciones del CORE las decide el ecosistema BJungle, no un calendario de releases ajeno.

Evolución

Capabilities alineadas

V2 (SAML bridge) y V3 (audit on-chain vía BLion · step-up contextual) incorporan capabilities que un IdP genérico no prioriza. El roadmap responde al ecosistema.

Multi-component

Un client_id por componente

BRhino, BLeopard, BGorilla, BPanther… cada componente tiene su client_id propio. La topología del ecosistema se modela en BMonkey, no en una consola externa.

Cómo se integra al ecosistema

3Estándar abierto, no SDK propietario.

BMonkey expone OIDC discovery + JWKS. Cualquier componente del ecosistema que entienda OpenID Connect consume el CORE sin SDK propietario. Cuando un componente nuevo entra al ecosistema, autentica contra BMonkey desde día 1.

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.

Multi-tenant + multi-component

4Un CORE · N componentes · M tenants.

Cada tenant B2B del ecosistema (banco, cooperativa, caja, aseguradora) tiene su tenant en BMonkey. Cada componente BJungle es un client_id distinto. Un único CORE sirve a N componentes y M tenants con aislamiento por tenant_id.

1
CORE de identidad en el ecosistema
N
Componentes BJungle conectados
M
Tenants del ecosistema aislados
OIDC
Protocolo único de integración
Cada componente recibe en el JWT el tenant_id del sujeto. Sobre ese claim filtra RLS, valida policies y resuelve scope. Cero código de tenant-routing en cada componente.
Frontera B2B vs B2C

5Cuatro líneas duras que separan B2B de B2C.

BMonkey es CORE del ecosistema B2B y vive en bjungle.net como pieza arquitectónica. Lo que era OnlyOne queda diferido a NewCo B2C en sitio separado. La separación no es de UX — es de estrategia.

1

BMonkey · CORE B2B

Pieza estructural del ecosistema BJungle (Capa 01). Cada tenant del ecosistema (banco, cooperativa, caja, aseguradora) tiene aislamiento por tenant_id. Vive en bjungle.net.

2

OnlyOne · Producto B2C

Wallet de identidad consumer-facing del usuario final. Se reactiva cuando se levante NewCo. Vivirá en sitio separado — no en bjungle.net.

3

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.

4

Sin colisión técnica

BMonkey emite JWT corporativos. OnlyOne emitirá Verifiable Credentials W3C consumer-facing. Estándares distintos, audiencias distintas.

Roadmap

6V1 → V2 → V3 sin fechas duras.

V1 · CORE base

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 del ecosistema B2B.

OIDCProtocolo base
RS256Firma de tokens
MultiTenant nativo

V1 · alcance greenfield del CORE

V2 · Empresa

MFA configurable por tenant. SSO empresarial vía SAML bridge para tenants con AD/Entra ID. Soporte de IdPs federados (Google Workspace, Azure AD) cuando el tenant del ecosistema lo exija.

MFAStep-up factor
SAMLBridge para AD
Fed.IdPs externos

V2 · integración con stacks corporativos del tenant

V3 · Audit on-chain + step-up

Eventos críticos de AuthN (login admin, token revocation, cambio de credencial) sellados on-chain vía BLion. Step-up auth contextual basado en señal de riesgo del componente.

BLionSealed events
Step-upAuth contextual
AuditTrail inmutable

V3 · trazabilidad regulatoria nativa

Preguntas frecuentes

7Lo que más nos preguntan.

¿BMonkey reemplaza a Auth0 / Cognito / Keycloak en mi institución?
No. BMonkey es el CORE de identidad del ecosistema BJungle — autentica a los usuarios que entran a los componentes BJungle. El IdP corporativo del cliente sigue autenticando lo que ya autenticaba. Si se requiere federación, BMonkey V2 incluye SAML bridge.
¿Se contrata BMonkey aparte?
No. BMonkey no se vende ni se contrata standalone. Es pieza estructural de la Capa 01 del ecosistema — soporta a los componentes desde adentro, sin pricing propio, sin tier comercial, sin SKU.
¿Cumple con LPDP / GDPR?
Sí. Multi-tenant con aislamiento por tenant nativo. Cada tenant del ecosistema es dueño de los datos de sus usuarios. BMonkey no agrega ni cruza data entre tenants — esa frontera es dura.
¿Federación contra Azure AD / Google Workspace?
Roadmap V2. SAML bridge + OIDC federation para tenants con IdP corporativo propio. V1 cubre el caso default (usuarios gestionados por BMonkey).
¿Y la autorización (roles, permisos)?
No es de BMonkey. Cada componente BJungle resuelve sus propias políticas RBAC y multi-tenant sobre los claims canónicos del JWT. Esa frontera es la decisión raíz (SPEC-AUTH §1).
¿Qué pasa con la decisión OnlyOne previa?
OnlyOne queda diferido a NewCo B2C (wallet consumer-facing). Su rol AuthN B2B en el ecosistema fue absorbido por BMonkey desde 2026-06-14. Decisión Javier + Jonhjar.
Componentes del ecosistema que consumen el CORE

8El ecosistema usa BMonkey para autenticar.

Cartera de crédito · Capa 02
BRhino
El ecosistema usa BMonkey para autenticar a los actores de cartera. Toda decisión de BRhino lleva <code>tenant_id</code> + <code>sub</code> del JWT canónico.
Comisiones · Capa 02
BLeopard
BLeopard recibe la identidad del backoffice y la fuerza comercial desde el CORE. Esquemas y liquidaciones aislados por tenant.
PQRS · Capa 02
BPanther
BPanther identifica al asesor y al cliente con un único protocolo OIDC. Chat, voz, email y formulario comparten la misma identidad.
eKYC · Capa 02
BFalcon
BFalcon reconoce sesiones autenticadas por el CORE y evita repetir KYC para clientes ya verificados en el ecosistema.
Core transaccional · Capa 01
BJaguar
Otro Core de Capa 01: BJaguar consume identidad del CORE de BMonkey — sin fabricar tabla de clientes propia.
Estrategia · Capa 03
BApex
BApex razona sobre histórico segmentado por <code>tenant_id</code> del JWT que entrega BMonkey.
BPM · ECM · BPO · Capa 01
BTiger
BTiger asigna tareas y custodia documental con la identidad que provee BMonkey al ecosistema.
Blockchain · Capa 01
BLion
Core ↔ Core: BLion sella eventos AuthN críticos (V3+) — login admin, token revocation, cambio de credencial.

El ecosistema BJungle usa BMonkey para autenticar a todos sus usuarios. La autorización vive en cada componente. El JWT canónico viaja sellado entre componentes — y en V3, los eventos AuthN críticos también van a blockchain.

Arquitectura

BMonkey es pieza estructural del ecosistema, no producto standalone.

BMonkey no se contrata por separado ni se demuestra como producto individual — se entiende mirando la arquitectura del ecosistema completo.

Conoce la arquitectura del ecosistema