Capítulo 17 — Gestión profesional de usuarios, roles y permisos¶

Recursos visuales propuestos¶

Antes de desarrollar este capítulo conviene distinguir qué recursos realmente mejoran el aprendizaje. Los conceptos de jerarquía, comparación entre roles y permisos, y flujos de administración se entienden mejor con imágenes didácticas porque presentan relaciones de forma rápida y pedagógica. En cambio, la interacción técnica entre Authentication, Admin SDK, Custom Claims, Firestore y reglas de seguridad exige diagramas SVG, ya que se trata de flujos de autorización, propagación de tokens y responsabilidades entre componentes del sistema.[cite:1][cite:2]

Imágenes didácticas¶

Jerarquía de roles. Conviene como imagen didáctica porque el lector necesita visualizar claramente niveles de responsabilidad dentro del sistema.
Comparación Roles vs Permisos. Debe resolverse como imagen didáctica porque ayuda a separar dos conceptos que suelen confundirse al diseñar autorización.
Flujo de administración de usuarios. Funciona mejor como imagen didáctica porque resume alta, actualización, bloqueo y baja de cuentas como proceso operativo.
Ejemplos de perfiles. Es una imagen útil para comparar qué parte vive en Authentication y qué parte debe vivir en Firestore.
Organización de usuarios dentro de una institución. Conviene como imagen didáctica porque permite ilustrar roles globales e institucionales sin sobrecargar al lector con notación técnica.

Diagramas SVG¶

Arquitectura completa de autenticación y autorización. Debe ser SVG porque representa cómo la identidad autenticada se transforma en control de acceso dentro del ecosistema.[cite:2]
Flujo de validación mediante Custom Claims. Conviene SVG porque implica Admin SDK, ID token, refresco de token, lectura de claims y posterior autorización.[cite:2]
Integración entre Authentication, Firestore, Admin SDK y Security Rules. Debe ser SVG porque muestra múltiples componentes con responsabilidades distintas en tiempo de ejecución.[cite:1][cite:2]
Modelo RBAC aplicado al proyecto del libro. También se recomienda SVG porque une jerarquía de roles, ámbitos institucionales y módulos habilitados.

Objetivos de aprendizaje¶

Al finalizar este capítulo, el lector será capaz de:

Comprender qué información almacena Firebase Authentication sobre un usuario y qué información no debe almacenarse allí.[cite:1][cite:2]
Administrar usuarios desde Firebase Console y desde el Firebase Admin SDK con criterio profesional.[cite:1]
Diseñar un sistema de roles y permisos seguro, escalable y mantenible.
Entender qué son las Custom Claims, cómo se asignan, cómo se propagan y cuáles son sus límites.[cite:2]
Distinguir entre autenticación y autorización, así como entre RBAC y ABAC.[cite:2]
Diseñar un modelo de acceso para la plataforma educativa del libro con superadministrador, administrador institucional, director, subdirector, docente, alumno, padre de familia e invitado.
Aplicar principios como mínimo privilegio, separación de responsabilidades y prevención de escalación de privilegios en un sistema real.

Introducción¶

Autenticar a un usuario es apenas el primer paso para construir una aplicación profesional. El verdadero reto aparece después: decidir con precisión qué puede ver, modificar, aprobar o administrar cada persona dentro del sistema. Esa segunda parte corresponde a la autorización y, en aplicaciones reales, suele ser mucho más compleja que el propio inicio de sesión.

Firebase Authentication resuelve la identidad, pero la administración profesional de usuarios exige diseñar una capa adicional de gobierno de acceso. La documentación oficial muestra que el Admin SDK permite crear usuarios, buscarlos por uid, correo o teléfono, listarlos por lotes, actualizarlos, deshabilitarlos y eliminarlos desde un entorno privilegiado del servidor.[cite:1] Esto convierte a Authentication no solo en un sistema de login, sino también en una base de administración centralizada de identidades.

Además, Firebase permite adjuntar atributos de control de acceso mediante Custom Claims. La documentación oficial indica que estas claims se definen solo desde el Admin SDK, se incluyen en el ID token del usuario y pueden utilizarse para implementar estrategias de control de acceso como RBAC en las reglas de seguridad.[cite:2] También aclara que no deben usarse para almacenar datos de perfil ni información arbitraria, y que su tamaño total no puede exceder 1000 bytes.[cite:2]

Este capítulo se concentra precisamente en esa capa intermedia entre identidad y acceso. Se explicará qué datos pertenecen a Authentication, cuáles deben vivir en Firestore, cómo diseñar roles globales e institucionales, cómo usar Custom Claims sin abusar de ellas, y cómo crear un modelo de administración profesional para la plataforma educativa del libro.

Desarrollo completo¶

Gestión de usuarios¶

¿Qué información almacena Firebase Authentication?¶

Firebase Authentication almacena la identidad básica del usuario y ciertos atributos esenciales para el proceso de autenticación. La documentación oficial del Admin SDK muestra que un usuario puede incluir datos como uid, correo electrónico, estado de verificación del correo, número de teléfono, contraseña, nombre visible, URL de foto y estado disabled.[cite:1]

Además, el servicio mantiene metadatos como fecha de creación y último inicio de sesión, accesibles al consultar el UserRecord desde el Admin SDK.[cite:1] Esta información es suficiente para administrar la identidad base, pero no para modelar completamente el dominio de negocio.

Por eso es importante distinguir desde el principio dos categorías:

Datos de identidad y autenticación: viven en Firebase Authentication.
Datos de negocio y perfil extendido: normalmente viven en Firestore.

Esta separación evita usar Authentication como si fuera una base de datos general de usuarios.

UID del usuario¶

La documentación oficial indica que el uid es la forma principal de identificar a un usuario y que puede tener entre 1 y 128 caracteres; si no se especifica al crear el usuario, Firebase genera uno aleatorio.[cite:1] También señala un detalle importante: los uid más cortos ofrecen mejor rendimiento.[cite:1]

Arquitectónicamente, el uid debe considerarse la clave maestra de identidad en Firebase. Todo perfil de Firestore, toda relación con instituciones, toda bitácora y toda referencia a permisos debería girar en torno a ese identificador. No conviene usar el correo como clave primaria porque puede cambiar; el uid, en cambio, es estable.

Perfil del usuario¶

Authentication puede almacenar un perfil básico: displayName, photoURL, correo, teléfono y estado de verificación.[cite:1] Sin embargo, esto no equivale al perfil funcional completo de la aplicación.

En el proyecto del libro, por ejemplo, un docente no solo necesita nombre y correo. También necesita institución, departamentos, materias, planteles, asignaciones, calendario, relación con grupos y estado operativo. Esos datos pertenecen a Firestore y no a Authentication. Esta decisión reduce acoplamiento y mantiene a Authentication centrado en identidad.

Metadata¶

La API de administración permite acceder a metadatos del usuario, incluyendo fecha de creación de la cuenta y fecha de último inicio de sesión.[cite:1] Estos metadatos son muy valiosos para auditoría básica, análisis de actividad y limpieza de cuentas inactivas.

No obstante, una organización profesional normalmente necesitará auditoría más rica: quién otorgó un rol, cuándo cambió un permiso, desde qué panel se ejecutó una baja, etcétera. Esa auditoría ampliada no la resuelve Authentication por sí solo y debe diseñarse en Firestore o en otro sistema de logging.

Estado de verificación¶

Firebase Authentication mantiene atributos como emailVerified, que indican si el correo del usuario ha sido verificado.[cite:1] Este dato es extremadamente útil porque permite introducir controles de confianza en el sistema.

Por ejemplo, un usuario podría autenticarse correctamente pero no obtener acceso a ciertos módulos sensibles hasta verificar su correo o hasta ser validado por un administrador institucional. En sistemas profesionales, autenticación no siempre implica confianza completa inmediata.

Usuarios deshabilitados¶

La documentación oficial permite crear usuarios inicialmente deshabilitados y habilitarlos más tarde, así como actualizar el atributo disabled de usuarios existentes.[cite:1] Esta capacidad es muy importante desde el punto de vista operativo.

Deshabilitar una cuenta suele ser mejor que eliminarla de inmediato en muchos escenarios:

suspensión temporal;
baja administrativa en revisión;
incidente de seguridad;
bloqueo preventivo;
espera de validación institucional.

La cuenta permanece trazable, pero sin acceso operativo.

Eliminación de usuarios¶

El Admin SDK permite eliminar usuarios por uid y también eliminarlos de forma masiva.[cite:1] Sin embargo, la documentación advierte un matiz muy importante: cuando se usa borrado por lotes con deleteUsers, los disparadores onDelete() de Cloud Functions no se ejecutan para cada usuario.[cite:1]

Este detalle tiene consecuencias arquitectónicas directas. Si el sistema necesita ejecutar limpieza de perfiles, revocar recursos, archivar actividad o actualizar índices cuando se elimina un usuario, no debe asumirse que la eliminación masiva disparará automáticamente esa lógica por cada cuenta.[cite:1]

Actualización de perfiles¶

El Admin SDK también permite actualizar correo, teléfono, estado de verificación, contraseña, nombre visible, foto y estado disabled sin necesidad de iniciar sesión como el usuario afectado.[cite:1] Esto es fundamental para administración centralizada.

En una plataforma educativa, por ejemplo, el área institucional puede corregir el nombre visible de un docente, actualizar su correo corporativo o deshabilitar su acceso sin pedirle que realice la operación desde el frontend.

Administración desde Firebase Console¶

La consola de Firebase es útil para inspección, soporte manual y operaciones puntuales. Permite revisar usuarios, proveedores y algunos aspectos básicos del estado de las cuentas. Sin embargo, en proyectos profesionales no conviene depender de la consola como herramienta principal de administración diaria.

La razón es simple: la consola es excelente para administración manual de bajo volumen, pero no para flujos institucionales, auditoría robusta, aprobación de altas, asignación compleja de roles o procesos masivos repetibles.

Administración mediante Firebase Admin SDK¶

La documentación oficial deja claro que el Admin SDK es la herramienta apropiada para gestión programática de usuarios con privilegios elevados.[cite:1] Desde un entorno de servidor seguro se pueden crear usuarios sin limitaciones de throttling, buscarlos por múltiples criterios, listarlos en lotes de hasta 1000, modificarlos y eliminarlos.[cite:1]

Esto permite construir un verdadero panel administrativo propio para la aplicación, alineado con las necesidades del negocio. En lugar de obligar al equipo operativo a entrar a la consola de Firebase para cada tarea, puede ofrecerse un módulo de administración institucional integrado al producto.

Roles¶

¿Qué es un rol?¶

Un rol es una abstracción que agrupa responsabilidades y capacidades de acceso. En lugar de asignar permiso por permiso a cada usuario, se define un conjunto coherente de privilegios y se lo asocia a una categoría funcional.

Ejemplos comunes son admin, moderator, teacher o student. La ventaja es reducir complejidad. En lugar de preguntar “¿puede este usuario editar notas, ver horarios, crear grupos y exportar reportes?”, la aplicación pregunta “¿qué rol tiene?” y deriva permisos desde ahí.

Roles vs permisos¶

Roles y permisos no son lo mismo.

Rol: categoría funcional de usuario.
Permiso: acción específica autorizada.

Por ejemplo, docente es un rol. crear_tarea, registrar_asistencia o ver_grupo_asignado son permisos. Diseñar bien esta diferencia mejora mantenibilidad, porque permite cambiar capacidades de un grupo completo sin reescribir la semántica del sistema.

Diseño de roles¶

Un buen diseño de roles debe seguir varios principios:

ser comprensible para el negocio;
evitar explosión combinatoria;
permitir evolución;
reflejar la estructura organizativa real;
no mezclar niveles globales con niveles institucionales de forma confusa.

Un error frecuente es crear roles demasiado específicos, como docente_matematicas_turno_vespertino_sede_norte. Eso no es un rol; es una mezcla de rol, atributos y contexto. La especialización fina debería vivir en atributos de Firestore o en relaciones de asignación, no en el nombre del rol.

Jerarquía de roles¶

No todos los roles tienen el mismo alcance. Una jerarquía bien diseñada permite ordenar responsabilidades.

Para el proyecto del libro se propone esta jerarquía conceptual:

Superadministrador.
Administrador institucional.
Director.
Subdirector.
Docente.
Alumno.
Padre de familia.
Invitado.

Esta jerarquía no implica necesariamente herencia automática de todos los permisos. Solo indica nivel de responsabilidad general. En seguridad profesional, jerarquía no debe confundirse con “acceso a todo”.

Roles globales¶

Los roles globales operan a nivel de toda la plataforma, no de una institución concreta. En el proyecto del libro, el mejor ejemplo es superadmin.

Un rol global debería ser excepcional y muy restringido. La mayoría de los usuarios no necesitan permisos globales. Mantener pocos roles globales reduce riesgo de escalación de privilegios y simplifica el modelo de autorización.

Roles por institución¶

La mayor parte de la lógica del proyecto debe vivir a nivel institucional. Un mismo usuario podría ser docente en una institución y padre de familia en otra. Eso demuestra por qué un único rol global no basta para modelar sistemas complejos.

Aquí aparece una decisión arquitectónica clave: los roles de ámbito institucional no deberían resolverse exclusivamente con Custom Claims permanentes si el usuario puede pertenecer a muchas organizaciones. Claims demasiado cargadas escalan mal y tienen límite de 1000 bytes.[cite:2] Para esos casos, suele ser mejor almacenar membresías y relaciones en Firestore, dejando en claims solo los privilegios globales o resumidos más críticos.

Roles por organización¶

En productos SaaS multiempresa o plataformas con múltiples sedes, campus u organizaciones, el rol puede depender del contexto activo. Un usuario puede ser administrador de la organización A, docente en la organización B e invitado en la organización C.

Esto empuja a un diseño híbrido:

claims para acceso global o banderas de alto nivel;
Firestore para relaciones detalladas y ámbitos organizacionales.

Custom Claims¶

¿Qué son?¶

La documentación oficial define las Custom Claims como atributos personalizados que el Admin SDK puede adjuntar a la cuenta del usuario para implementar control de acceso, incluyendo RBAC.[cite:2] Estas claims se incluyen en el ID token y luego pueden ser utilizadas por reglas de seguridad o backends validados.[cite:2]

Un ejemplo clásico es establecer { admin: true } para distinguir usuarios con privilegios administrativos.[cite:2]

Funcionamiento¶

Su funcionamiento es conceptualmente simple:

Un entorno privilegiado del servidor decide que un usuario debe recibir cierto atributo de acceso.
El Admin SDK escribe esas claims en la cuenta del usuario.[cite:2]
Las claims aparecen en el próximo ID token emitido o tras refrescar el token.[cite:2]
El cliente puede leerlas desde el resultado del token para ajustar la UI.
El backend o las reglas pueden utilizarlas como fuente confiable de autorización.[cite:2]

Cómo se asignan¶

La documentación es explícita: las Custom Claims deben definirse solo desde un entorno privilegiado del servidor mediante el Firebase Admin SDK.[cite:2] Esto es una exigencia de seguridad fundamental. Si el cliente pudiera asignarse sus propias claims, todo el modelo de acceso quedaría roto.

Cómo se leen¶

Las claims pueden leerse de dos formas principales:

en backend o procesos seguros, verificando el ID token y leyendo sus claims;[cite:2]
en el cliente, recuperando el IdTokenResult para adaptar la interfaz.[cite:2]

La documentación insiste en un punto crucial: aunque el cliente pueda leer claims para decidir qué mostrar, el acceso real debe ser validado por backend o reglas usando el token verificado.[cite:2]

Limitaciones¶

Firebase establece varias restricciones importantes sobre las Custom Claims:[cite:2]

solo deben usarse para control de acceso;
no están diseñadas para almacenar perfiles ni datos arbitrarios;
el payload total no debe superar 1000 bytes;
deben ser serializables a JSON;
no pueden usar nombres reservados de OIDC ni nombres reservados de Firebase.

Estas limitaciones explican por qué un diseño profesional no debe intentar meter toda la información del usuario dentro del token.

Buenas prácticas¶

De la documentación y de la práctica arquitectónica surgen varias reglas sólidas:[cite:2]

usar claims para privilegios de acceso y no para datos de perfil;
mantenerlas pequeñas y estables;
asignarlas solo desde backend confiable;
asumir que los cambios no son instantáneos hasta que el token se renueva o se fuerza refresco;[cite:2]
combinar claims con datos en Firestore cuando la autorización requiere contexto rico.

Autorización¶

Diferencia entre autenticación y autorización¶

Authentication responde “quién eres”. Authorization responde “qué puedes hacer”. La documentación oficial sobre claims lo deja claro al explicar que las claims sirven para implementar estrategias de control de acceso en reglas y backends.[cite:2]

Un usuario puede estar autenticado y seguir sin permiso para ver cierto módulo. Esa diferencia es lo que impide que un login correcto se convierta automáticamente en acceso universal.

Control de acceso¶

El control de acceso es el conjunto de decisiones que permiten o niegan acciones sobre recursos. En Firebase, ese control suele apoyarse en varias capas:

identidad del usuario en Authentication;
claims resumidas para privilegios clave;
datos de contexto en Firestore;
validación de token en backend;
reglas de seguridad en los servicios que las soportan.[cite:2]

Autorización basada en roles (RBAC)¶

RBAC asigna permisos a roles y luego asigna usuarios a esos roles. Es el modelo más intuitivo para organizaciones y equipos operativos porque se alinea bien con la estructura humana del negocio.

Ejemplos:

un docente puede registrar asistencia y calificaciones;
un director puede ver reportes institucionales;
un alumno puede consultar tareas;
un invitado solo puede acceder a áreas públicas.

Firebase menciona explícitamente que las Custom Claims permiten implementar control de acceso basado en roles.[cite:2]

Autorización basada en atributos (ABAC)¶

ABAC toma decisiones usando atributos, no solo roles. Por ejemplo:

institución activa del usuario;
plantel;
grupo asignado;
grado;
relación padre-hijo;
estado del documento;
horario o contexto operacional.

ABAC es más flexible y expresivo, pero también más complejo. Normalmente necesita datos en Firestore y lógica más rica que un simple booleano admin: true.

Cuándo utilizar cada una¶

La recomendación profesional suele ser híbrida:

usar RBAC para privilegios estructurales y comprensibles;
usar ABAC para restricciones de contexto fino.

En el proyecto del libro, por ejemplo:

docente es rol;
“solo puede editar materias de sus grupos asignados” es atributo/contexto.

Administración profesional¶

Alta de usuarios¶

La documentación oficial permite crear usuarios programáticamente con propiedades como correo, teléfono, contraseña, nombre visible y estado disabled.[cite:1] Esto habilita flujos de alta controlados por la organización.

En un sistema profesional, el alta debería considerar:

origen de la solicitud;
validación institucional;
asignación inicial de rol;
creación del perfil extendido en Firestore;
auditoría de quién creó la cuenta.

Baja de usuarios¶

La baja no siempre implica eliminación inmediata. A menudo conviene un flujo en etapas:

deshabilitar acceso;
conservar auditoría;
archivar relaciones activas;
eliminar o anonimizar más tarde si la política lo requiere.

Esto es especialmente importante en educación, donde pueden existir calificaciones, asistencias y trazas históricas vinculadas a una cuenta.

Bloqueo de cuentas¶

El atributo disabled del usuario es una herramienta ideal para bloqueo administrativo o preventivo.[cite:1] A diferencia de la eliminación, conserva integridad histórica y evita pérdida inmediata de referencias.

Restablecimiento de acceso¶

Restablecer acceso implica más que cambiar contraseña. Puede incluir reactivar la cuenta, restaurar claims, revisar perfil, invalidar sesiones comprometidas y revalidar la pertenencia del usuario a una institución.

Auditoría¶

Authentication ofrece datos útiles, pero la auditoría profesional debe registrar eventos de gobierno:

alta de usuario;
modificación de rol;
asignación y revocación de claims;
deshabilitación;
reactivación;
eliminación;
qué actor ejecutó la operación.

La auditoría debe vivir en almacenamiento propio, no solo depender de observar el estado actual del usuario.

Administración masiva¶

El Admin SDK permite listar usuarios en lotes de hasta 1000 y eliminarlos también en forma masiva.[cite:1] Esto hace posible sincronizaciones, campañas de limpieza, migraciones o reconciliación con directorios externos.

Sin embargo, administración masiva requiere extremo cuidado. Las operaciones en lote deben incorporar controles adicionales, confirmaciones, bitácoras y en lo posible procesos idempotentes.

Buenas prácticas de administración¶

usar panel administrativo propio respaldado por backend seguro;
separar operaciones manuales de procesos masivos;
registrar auditoría de toda operación sensible;
preferir deshabilitar antes que eliminar cuando exista impacto histórico;
mantener sincronización clara entre Authentication y Firestore;
tratar el uid como clave canónica del sistema.

Seguridad¶

Protección de cuentas privilegiadas¶

Las cuentas privilegiadas deben ser pocas, claramente identificadas y sujetas a procesos estrictos. Cuantas más cuentas de alto nivel existan, mayor superficie de riesgo tendrá la aplicación.

En el proyecto del libro, superadmin debe ser extremadamente limitado. El resto de la administración debería descentralizarse en administradores institucionales y no concentrarse en una cuenta global omnipotente.

Principio de mínimo privilegio¶

Este principio indica que cada usuario debe tener únicamente los privilegios estrictamente necesarios para cumplir su función. Es una de las mejores defensas contra errores humanos, abuso interno y escalación de privilegios.

Aplicado al proyecto:

un docente no necesita ver configuración global;
un director no necesita acceso a todas las instituciones;
un padre de familia no debe consultar información de alumnos ajenos;
un invitado no debe acceder a recursos privados aunque esté autenticado.

Separación de responsabilidades¶

No conviene que una sola cuenta pueda hacer todo. Una administración profesional distribuye facultades:

superadmin: operaciones globales excepcionales;
administrador institucional: operación de su institución;
director: gobierno académico local;
subdirector: apoyo operativo;
docente: operación pedagógica;
alumno y padre: acceso de consumo;
invitado: acceso restringido.

Esta separación no solo mejora seguridad; también mejora gobernanza y trazabilidad.

Prevención de escalación de privilegios¶

La documentación de claims subraya que estas solo deben asignarse desde backend privilegiado.[cite:2] Esa es la primera gran defensa contra escalación de privilegios.

Además, para evitar escalación se recomienda:

nunca permitir que el cliente decida directamente claims o roles críticos;
validar elegibilidad antes de asignar claims;
usar procesos aprobatorios para roles altos;
registrar todo cambio de privilegio;
evitar que un administrador de bajo nivel pueda promocionarse a sí mismo.

Buenas prácticas de seguridad¶

usar claims solo para acceso, no para datos arbitrarios.[cite:2]
mantener claims pequeñas y fáciles de auditar.[cite:2]
basar privilegios de alto impacto en backend confiable y datos institucionales verificables.
reducir el número de roles globales.
combinar RBAC con atributos contextuales.
proteger especialmente altas, bajas y modificaciones de privilegios.

Diseño del sistema del proyecto transversal¶

Modelo de usuarios propuesto¶

Para la plataforma educativa del libro se propone un modelo híbrido:

Authentication almacena identidad base: uid, correo, teléfono, nombre visible, foto, verificación, estado de cuenta y claims globales o resumidas.[cite:1][cite:2]
Firestore almacena perfil extendido, membresías institucionales, relaciones familiares, asignaciones académicas, permisos de módulo y auditoría.

Esta separación resuelve bien el equilibrio entre rendimiento, claridad y escalabilidad.

Roles propuestos¶

Rol	Ámbito	Responsabilidad principal	Restricciones principales
Superadministrador	Global	Gobernanza total de la plataforma	Uso excepcional; no operación diaria
Administrador institucional	Institución	Configuración y administración de su institución	No puede operar fuera de su institución
Director	Institución/plantel	Supervisión académica y operativa	Sin acceso global a plataforma
Subdirector	Institución/plantel	Apoyo de gestión y continuidad operativa	Privilegios menores que director
Docente	Académico	Gestión de grupos, tareas, asistencia y evaluación	Solo sobre sus grupos y recursos
Alumno	Académico	Acceso a cursos, tareas y materiales propios	Sin administración
Padre de familia	Relación familiar	Consulta de información de hijos vinculados	Solo datos autorizados de sus dependientes
Invitado	Restringido	Exploración o acceso puntual	Sin acceso a módulos privados

Claims recomendadas¶

Claims sugeridas para el proyecto:

superadmin: true/false
platformAdmin: true/false
institutionAdmin: true/false solo cuando tenga sentido resumido
role: 'superadmin' | 'institution_admin' | 'director' | ... en implementaciones simples
accessLevel para banderas resumidas de alto nivel cuando haga falta.[cite:2]

No se recomienda meter listas completas de instituciones, grupos o permisos detallados en claims, porque su tamaño es limitado y están pensadas para control de acceso compacto.[cite:2]

Permisos y módulos¶

Los permisos finos deberían almacenarse y resolverse desde el perfil institucional y las relaciones del usuario en Firestore. Por ejemplo:

canManageInstitutionSettings
canCreateTeacherAccounts
canEditGrades
canViewOwnChildrenReports
canUploadEvidence

Estos permisos pueden derivarse del rol y del contexto activo. No es necesario convertir cada permiso en una claim.

Casos reales¶

Plataforma educativa¶

En una plataforma educativa, un mismo usuario puede tener distintos papeles según el contexto. Un docente puede además ser padre de familia. Un director puede dar clases. Un invitado puede convertirse luego en alumno.

Por eso conviene evitar un modelo simplista donde cada usuario tenga un único rol estático. Authentication aporta la identidad estable; Firestore aporta las relaciones contextuales; Claims aportan banderas confiables de acceso resumido.

Sistema administrativo¶

En un sistema administrativo, los usuarios suelen tener menos variedad contextual y más necesidad de trazabilidad. Ahí RBAC puro funciona mejor: administrativo, supervisor, auditor, gerente. Aun así, los permisos sensibles nunca deberían depender solo de la UI; deben validarse con token verificado y reglas o backend.

Aplicación empresarial¶

En aplicaciones empresariales con directorios corporativos, las claims son útiles para trasladar banderas de acceso resumidas al token y evitar consultas extra en cada solicitud.[cite:2] Sin embargo, la organización fina de equipos, sedes o unidades de negocio suele vivir mejor en la base de datos o en el proveedor corporativo de identidad.

SaaS multiempresa¶

En un SaaS multiempresa, el gran reto es el aislamiento entre tenants. Un usuario puede ser administrador de una empresa y usuario simple de otra. Claims globales demasiado rígidas pueden quedarse cortas; por eso suele preferirse un modelo híbrido donde la pertenencia a tenant y el rol por tenant vivan en Firestore, con claims solo para categorías globales o banderas de alto nivel.

Comparaciones técnicas¶

Authentication vs Firestore para datos de usuario¶

Tipo de dato	Authentication	Firestore	Recomendación
UID	Sí [cite:1]	Puede replicarse como referencia	Usar Authentication como fuente canónica
Correo y verificación	Sí [cite:1]	Solo si el dominio lo necesita replicado	Authentication
Nombre visible y foto	Sí [cite:1]	Puede duplicarse si la app lo necesita	Depende del caso
Rol global resumido	Mediante claims [cite:2]	Sí	Claims para acceso, Firestore para gobierno
Membresías institucionales	No ideal	Sí	Firestore
Permisos detallados	No ideal [cite:2]	Sí	Firestore
Metadatos de creación/último acceso	Sí [cite:1]	Opcional	Authentication
Auditoría administrativa	No suficiente	Sí	Firestore u otro sistema

RBAC vs ABAC¶

Modelo	Ventaja principal	Limitación principal	Cuándo usarlo
RBAC	Simple, entendible y gobernable	Puede quedarse corto en contextos complejos	Roles institucionales y módulos
ABAC	Flexible y expresivo	Mayor complejidad	Restricciones por contexto, grupo o relación
Híbrido	Equilibrio entre claridad y precisión	Requiere diseño cuidadoso	Aplicaciones profesionales como el proyecto del libro

Buenas prácticas¶

Tratar el uid como identidad maestra y usarlo para enlazar todos los perfiles.[cite:1]
Mantener Authentication para identidad y Firestore para dominio de negocio.
Asignar Custom Claims solo desde backend privilegiado mediante Admin SDK.[cite:2]
Usar claims solo para acceso, no para perfiles ni listas enormes de datos.[cite:2]
Diseñar pocos roles, claros y alineados con la operación real.
Usar RBAC para estructura y ABAC para contexto.
Preferir deshabilitar antes que eliminar cuando exista historial relevante.[cite:1]
Diseñar auditoría propia para cambios de acceso.
Tener procesos explícitos para altas, bajas, promociones y revocaciones.
Evitar cualquier posibilidad de autoasignación de privilegios desde cliente.

Errores comunes¶

Guardar todo el perfil del usuario en Authentication.
Usar claims como si fueran una mini base de datos de permisos.
Asignar claims desde código cliente o confiar en valores enviados por el frontend.
Crear demasiados roles específicos y volver inmanejable el sistema.
No distinguir roles globales de roles institucionales.
Eliminar usuarios masivamente sin considerar efectos colaterales sobre auditoría o automatizaciones; además deleteUsers no dispara onDelete() por cada usuario.[cite:1]
Suponer que un cambio de claims es instantáneo sin contemplar renovación del token.[cite:2]
Diseñar permisos sin principio de mínimo privilegio.

Resumen¶

La administración profesional de usuarios en Firebase Authentication comienza entendiendo que Authentication no es toda la gestión del usuario, sino la capa de identidad base. El servicio almacena datos esenciales como uid, correo, teléfono, verificación, perfil básico, estado de cuenta y metadatos, y el Admin SDK permite crear, consultar, listar, actualizar, deshabilitar y eliminar usuarios desde un entorno privilegiado.[cite:1]

Para construir aplicaciones profesionales, esa identidad debe complementarse con un modelo de autorización bien diseñado. Las Custom Claims permiten adjuntar atributos de acceso al token del usuario y usarlos para estrategias como RBAC, pero solo deben definirse desde backend seguro, deben mantenerse pequeñas y usarse exclusivamente para control de acceso, no para almacenar perfiles ni información arbitraria.[cite:2]

En sistemas reales, la mejor arquitectura suele ser híbrida: Authentication para identidad, Claims para privilegios resumidos y confiables, Firestore para membresías, relaciones y contexto detallado. Aplicado al proyecto del libro, este enfoque permite modelar superadministradores, administradores institucionales, directores, subdirectores, docentes, alumnos, padres de familia e invitados de forma segura, escalable y mantenible.

Conceptos clave¶

Firebase Authentication.
Gestión de usuarios.
uid.[cite:1]
UserRecord.[cite:1]
Perfil básico.
Metadata de usuario.[cite:1]
Cuenta deshabilitada.[cite:1]
Admin SDK.[cite:1]
Rol.
Permiso.
Rol global.
Rol institucional.
RBAC.
ABAC.
Custom Claims.[cite:2]
ID token.[cite:2]
Propagación de claims.[cite:2]
Principio de mínimo privilegio.
Separación de responsabilidades.
Escalación de privilegios.

Preguntas de repaso¶

¿Qué información almacena Firebase Authentication de forma nativa sobre un usuario?[cite:1]
¿Por qué el uid debe considerarse la identidad canónica del sistema?[cite:1]
¿Qué diferencia práctica existe entre rol y permiso?
¿Por qué no conviene guardar membresías institucionales complejas dentro de Custom Claims?[cite:2]
¿Cómo se asignan correctamente las Custom Claims y por qué no deben definirse desde el cliente?[cite:2]
¿Qué limitaciones técnicas tienen las Custom Claims?[cite:2]
¿Cuándo conviene usar RBAC y cuándo ABAC?
¿Por qué a menudo es preferible deshabilitar una cuenta antes que eliminarla?[cite:1]
¿Qué implicación tiene el hecho de que deleteUsers() no dispare onDelete() por cada usuario?[cite:1]
¿Qué modelo de usuarios y acceso resulta más adecuado para la plataforma educativa del libro?

Ejercicios prácticos¶

Diseña el documento de perfil de Firestore para un docente enlazado a su uid de Authentication.
Propón una matriz de permisos para superadministrador, administrador institucional, director, subdirector, docente, alumno, padre e invitado.
Define qué atributos colocarías en Custom Claims y cuáles dejarías en Firestore, justificando cada decisión.[cite:2]
Redacta un flujo de alta de usuario institucional usando Admin SDK, perfil en Firestore y auditoría administrativa.[cite:1]
Diseña un procedimiento de suspensión temporal de cuenta que preserve historial y permita reactivación posterior.
Analiza un caso de escalación de privilegios posible en el frontend y explica cómo evitarlo.
Propón un modelo híbrido RBAC + ABAC para que un docente solo pueda editar grupos asignados y un director solo ver su plantel.
Describe cómo construirías un panel administrativo propio para gestionar usuarios en lugar de depender exclusivamente de Firebase Console.

Bibliografía y referencias oficiales¶

Manage Users | Firebase Authentication: https://firebase.google.com/docs/auth/admin/manage-users [cite:1]
Control Access with Custom Claims and Security Rules: https://firebase.google.com/docs/auth/admin/custom-claims [cite:2]
Security Rules and Firebase Authentication: https://firebase.google.com/docs/rules/rules-and-auth [cite:3]