El IdP solo autentica. No hay catálogo de permisos, ni roles por cliente
ni tablas de autorización. La autorización de grano fino vive en cada
cliente; las APIs de B Brands usan su RBAC interno existente.
1. Modelo lógico
Convenciones comunes en cada entidad: una clave primaria UUID, campos de seguimiento estándar (timestamps de creación/actualización/eliminación y flags de soft-delete), integridad referencial restringida, y controles de acceso a nivel de fila.2. Entidades
Registro de clientes OAuth
Contiene un registro por cliente registrado, con unclient_handle estable (p. ej.
erp-dev), un display name visible por humanos, platform_type (agent, analytics,
crm, erp, internal_tool, partner), trust_level (first_party,
partner, public), status (active, suspended, revoked), id_token_alg
(ES256 por defecto, RS256 — el id_token_signed_response_alg de OIDC: con
RS256, el IdP re-firma el id_token del cliente con su clave RSA para que las
librerías que solo validan RS256, como el módulo OCA auth_oidc de Odoo,
funcionen sin modificaciones), las redirect URIs registradas (coincidencia
exacta), un TTL de token de acceso por cliente, y el target del webhook de
provisioning más su secreto de firma. El secreto del webhook nunca se devuelve
después de su creación.
Acceso usuario × plataforma
La entidad central de habilitación. Sin rol, sin permisos. Un usuario puede tener a lo sumo una habilitación activa por cliente. El hook de token de acceso y el exchange ambos verificanstatus = 'active' y que la habilitación no haya expirado. Registra
quién otorgó el acceso, la expiración opcional, y los datos de revocación (cuándo, por quién, motivo).
Registros y auditoría
Registro de autorización
Registro de autorización
Decisiones de consentimiento (
approve/deny), los scopes solicitados, un correlation id,
metadatos de la solicitud (IP, user agent) y referencias al cliente y al usuario.Registro de emisión de tokens
Registro de emisión de tokens
Tipo de grant (
authorization_code / refresh_token / token_exchange), tipo de token
(oidc_identity / internal_exchange), jti, expiración y un correlation
id. Append-only, best-effort.Blacklist de tokens
Blacklist de tokens
El
jti del token revocado, el tipo de token, el motivo (p. ej. oauth_revocation), la expiración
(para la limpieza) y quién lo revocó.Cola de provisioning
Cola de provisioning
Tipo de evento (
user_provisioned / user_deprovisioned / user_suspended /
user_reactivated), estado de entrega (pending / in_flight / delivered /
failed / dead_letter), el payload, el conteo de intentos, el próximo tiempo de reintento y el
último error.Auditoría de administración
Auditoría de administración
La acción (cliente creado/actualizado/suspendido/revocado, secreto rotado, acceso
otorgado/suspendido/revocado/reactivado, …), el actor, el cliente/usuario objetivo,
un correlation id y metadatos de la solicitud.
3. Resolución de identidad y revocación
Una única rutina de resolución es llamada por el hook de token de acceso. Valida que el cliente esté activo y el usuario habilitado, y devuelve el payload de identidad (o un motivo estructurado de “no habilitado” en lugar de lanzar, para que el hook pueda responder unaccess_denied limpio). El payload también lleva la dimensión de cuenta de
negocio: la cuenta vinculada al usuario mediante el rol primary_user y el id
del sistema externo de esa cuenta (null si no está mapeada). Un payload
resuelto típico:
- Revocar una única habilitación para un usuario en un cliente.
- Kill switch: revocar todas las habilitaciones activas/suspendidas de un usuario en cada cliente a la vez. Cada transición dispara un evento de provisioning.