# Sacamos el plugin de auth y escribimos nuestro propio RBAC

- Fecha: 22 de agosto de 2026
- Proyecto: restoman
- Tags: Arquitectura, Backend, Auth

> El plugin de organizations de Better Auth modela una empresa plana. Un grupo gastronómico es una jerarquía, y los permisos tienen que heredar hacia abajo sin escalar nunca hacia arriba. Doblar el plugin habría costado más que reemplazarlo.

El plugin no estaba mal. Modela lo que la mayoría de los productos necesita:
una empresa, sus miembros, y roles adentro. Plano.

Un grupo gastronómico no es plano. Hay un grupo, sus locales, los pisos de un
local, y las estaciones de una cocina. Un encargado a nivel local debería
heredar todo lo de abajo y nada de al lado. Eso no es una lista de roles: es un
árbol con una regla de no-escalación.

## La alternativa que descartamos

Dejar el plugin y modelar la jerarquía al lado — una segunda tabla mapeando
miembros a scopes, consultada después de que el plugin contestara. Habría
funcionado, y habría significado dos fuentes de verdad para una pregunta. Cada
chequeo de permiso habría tenido que preguntarle a las dos y reconciliar, y la
primera vez que no coincidieran tendríamos un bug de seguridad y no uno de
renderizado.

## Qué hicimos en cambio

Organizaciones, membresía y scopes en nuestro propio schema, con la herencia
resuelta **por permiso** y no por rol. No "un encargado puede hacer X", sino
"este permiso hereda hacia abajo desde el scope donde se otorgó".

El costo fue real: es más código y ahora es nuestro. Lo que lo hace la decisión
correcta es que los permisos son la única parte de este sistema donde estar
aproximadamente bien es lo mismo que estar mal.

---

Página: https://eitanf.com/es/notes/we-wrote-our-own-rbac · English: https://eitanf.com/notes/we-wrote-our-own-rbac.md · llms.txt: https://eitanf.com/llms.txt