1. Capas de componentes
El sistema se compone de cinco capas lógicas que viven en piezas físicas distintas.2. Cómo se organiza el código
La lógica del IdP es un módulo transversal, separado del patrón estándar por recurso del resto de la API.3. Decisiones arquitectónicas clave (ADR-lite)
ADR-01 — Un motor OAuth 2.1 administrado como motor del protocolo
ADR-01 — Un motor OAuth 2.1 administrado como motor del protocolo
iss/aud y
aplicar la habilitación. Contrapartida: dependemos de las capacidades del motor; la
falta de scopes personalizados nativos es irrelevante porque no inyectamos
permisos en los tokens.ADR-02 — Envoltura completa de los endpoints OAuth detrás del origen de B Brands
ADR-02 — Envoltura completa de los endpoints OAuth detrás del origen de B Brands
ADR-03 (revisado) — Issuer canónico = https://auth.bbrands.io (por entorno)
ADR-03 (revisado) — Issuer canónico = https://auth.bbrands.io (por entorno)
iss de los tokens de acceso emitidos es la URL auth.* del entorno
(p. ej. https://development.auth.bbrands.io en development), reescrita por
el hook de token de acceso. Un token no productivo nunca es válido en producción
porque los clientes validan el iss contra su propio entorno. Esto revisa
la decisión original que nombraba a api.* como el issuer.ADR-03b (revisado) — Un único origen de identidad de cara al usuario: auth.*
ADR-03b (revisado) — Un único origen de identidad de cara al usuario: auth.*
auth.* sirve tanto las superficies interactivas (login,
consentimiento) como cada endpoint del protocolo (discovery, JWKS, authorize, token,
userinfo, revoke) — estos últimos mediante reescrituras transparentes al backend api.*.
Esta es la forma de accounts.google.com: un origen de identidad estable
para los clientes, mientras que el host de implementación detrás de él permanece
reemplazable. Verificaciones de consistencia en el arranque y un monitor de disponibilidad de JWKS
protegen el contrato.ADR-04 — Firma asimétrica (ES256) para los tokens OAuth
ADR-04 — Firma asimétrica (ES256) para los tokens OAuth
ADR-04b — Re-firma RS256 del id_token por cliente
ADR-04b — Re-firma RS256 del id_token por cliente
auth_oidc) se registran con id_token_alg: "RS256" (el
id_token_signed_response_alg de OIDC). Solo para esos clientes, el IdP
verifica el id_token ES256 genuino y lo re-firma con su propia clave RSA,
preservando todos los claims. El JWKS publica la clave pública RSA junto a
la clave EC, el discovery anuncia ambos algoritmos, y el token de acceso
nunca se re-firma. Cualquier fallo de re-firma vuelve al original ES256.ADR-05 — El IdP no inyecta permisos en los tokens
ADR-05 — El IdP no inyecta permisos en los tokens
sub, email, perfil). No hay
claim de permiso ni de rol. El hook de token de acceso solo reescribe iss/aud y
verifica que el usuario esté habilitado para el cliente.ADR-06 — Una única fuente de verdad para la identidad
ADR-06 — Una única fuente de verdad para la identidad
ADR-07 — Provisioning por pre-sincronización vía webhook (no JIT)
ADR-07 — Provisioning por pre-sincronización vía webhook (no JIT)
ADR-08 — TTL corto + blacklist para una revocación efectiva
ADR-08 — TTL corto + blacklist para una revocación efectiva
ADR-09 — Exchange OIDC → JWT interno para consumir las APIs de B Brands
ADR-09 — Exchange OIDC → JWT interno para consumir las APIs de B Brands
4. La pieza central: el hook de token de acceso
El hook no inyecta permisos. Su trabajo es reescribiriss/aud, validar
que el usuario esté habilitado para el cliente y adjuntar la dimensión de
cuenta de negocio (https://bbrands.io/profile). Si el usuario no está
habilitado, no se emite ningún token (denegación por defecto seguro).
5. Aislamiento por cliente
Aunque cada cliente comparte una instancia del motor, el aislamiento se garantiza mediante:- El claim
https://bbrands.io/client_handleque identifica al cliente solicitante en cada token de acceso OAuth (audes la audiencia fijabbrands-idp). - La validación de
client_handlepor cada cliente (un token paracrm-prodno es válido en un cliente ERP). - La habilitación mediante el registro de acceso usuario × plataforma, verificada en la emisión, el exchange y el refresh.
- El registro de auditoría filtrado por
client_handle.