Saltar a contenido

Capítulo 15 — Introducción a Firebase Authentication

Recursos visuales propuestos

Antes de desarrollar este capítulo conviene decidir qué recursos visuales realmente facilitan la comprensión del lector. En autenticación, muchos conceptos base —como autenticación frente a autorización o el ciclo de vida de una sesión— se entienden mejor con imágenes didácticas claras y progresivas. En cambio, los flujos internos de emisión de tokens, validación de identidad e integración con Security Rules y Google Identity Platform necesitan diagramas técnicos más precisos.

Imágenes didácticas

  1. Autenticación vs autorización. Conviene como imagen didáctica porque ayuda a separar dos conceptos que suelen confundirse al iniciar en seguridad de aplicaciones.
  2. Flujo básico de inicio de sesión. Es una imagen didáctica útil porque muestra de forma simple la secuencia usuario → aplicación → Firebase Authentication → sesión autenticada.
  3. Ciclo de vida de un usuario autenticado. También encaja como imagen didáctica porque permite visualizar registro, inicio de sesión, persistencia de sesión, renovación de token y cierre de sesión.
  4. Componentes principales de Firebase Authentication. Conviene como imagen didáctica porque introduce la relación entre usuario, credenciales, tokens, sesión y reglas sin exigir todavía una vista de arquitectura completa.
  5. Relación entre usuario, aplicación y Firebase. Es útil como imagen didáctica porque sitúa a Authentication como puerta de entrada al ecosistema del proyecto.

Diagramas SVG

  1. Arquitectura completa de Firebase Authentication. Debe ser SVG porque necesita mostrar cliente, SDK, proveedor de identidad, servicio de autenticación, emisión de tokens, persistencia de sesión e integración con otros servicios.
  2. Flujo interno entre cliente, Authentication, Firestore y Security Rules. Conviene SVG porque describe una interacción técnica entre múltiples componentes de la plataforma.[cite:2]
  3. Emisión y validación de tokens. Debe ser SVG porque el lector necesita distinguir ID Token, Refresh Token y uso del contexto autenticado en reglas y backend.[cite:1][cite:2]
  4. Integración con Google Identity Platform. También se recomienda SVG porque se trata de una relación de infraestructura y servicio más compleja que una simple ilustración.

Objetivos de aprendizaje

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

  • Comprender qué es la autenticación y por qué es el primer paso para construir aplicaciones seguras y personalizadas.
  • Distinguir con claridad autenticación y autorización.
  • Entender los conceptos de identidad digital, credenciales, sesiones y tokens.
  • Comprender qué papel cumplen JWT, ID Token, Refresh Token y Access Token dentro del ecosistema moderno de autenticación.
  • Explicar qué es Firebase Authentication, cómo se relaciona con Google Identity Platform y cómo encaja dentro de la plataforma Firebase.
  • Describir el flujo general que ocurre desde que un usuario inicia sesión hasta que obtiene acceso a Firestore, Storage y otras partes de la aplicación.[cite:1][cite:2]
  • Preparar la base conceptual necesaria para implementar métodos de autenticación en los capítulos siguientes.

Introducción

Toda aplicación moderna necesita responder una pregunta esencial: ¿quién es el usuario que intenta entrar? Sin esa respuesta no es posible personalizar la experiencia, proteger información privada, delimitar permisos ni construir flujos coherentes entre módulos. La autenticación resuelve precisamente esa necesidad. No se limita a “permitir iniciar sesión”, sino que establece la identidad digital sobre la cual se apoya el resto de la arquitectura de acceso.

Firebase Authentication es uno de los servicios más importantes de Firebase porque convierte la identidad en un componente administrado de la plataforma. En lugar de diseñar desde cero un sistema propio de credenciales, sesiones, tokens y recuperación de acceso, el desarrollador puede apoyarse en una infraestructura de identidad ya integrada con el resto del ecosistema Firebase. Esta integración es especialmente relevante porque las Security Rules utilizan la información autenticada del usuario por medio de request.auth y auth.token para decidir acceso en Firestore, Realtime Database y Cloud Storage.[cite:2]

La documentación oficial sobre persistencia de sesión en web muestra además que Authentication no solo verifica identidad; también gestiona cómo esa identidad se conserva en el tiempo. El SDK de JavaScript permite persistencia local, session o none, y en aplicaciones web el comportamiento por defecto es persistir la sesión incluso después de cerrar el navegador, salvo que el desarrollador decida otra estrategia.[cite:1] Esto demuestra que autenticación no es un evento puntual, sino un ciclo de vida continuo.

En este capítulo no se implementará todavía ningún método de autenticación. El objetivo es comprender el servicio: qué problema resuelve, cómo administra la identidad, qué ocurre internamente con los tokens, cómo se integra con Firestore, Functions, Storage y Security Rules, y cómo servirá de puerta de entrada para administradores, docentes, alumnos, personal de apoyo e invitados dentro del proyecto oficial del libro.

Desarrollo completo

¿Qué es la autenticación?

La autenticación es el proceso de verificar que una entidad es realmente quien dice ser. En una aplicación digital, esa entidad suele ser un usuario humano, aunque también puede ser un servicio, un dispositivo o un backend.

En términos simples, autenticarse significa demostrar identidad. Esa demostración puede basarse en algo que el usuario sabe, como una contraseña; algo que posee, como un dispositivo o número de teléfono; o algo que es, como un factor biométrico. Firebase Authentication abstrae muchos de esos mecanismos, pero el principio general sigue siendo el mismo: antes de conceder acceso, el sistema necesita una prueba razonable de identidad.

Autenticación vs autorización

Uno de los errores conceptuales más comunes es confundir autenticación con autorización.

  • Autenticación responde: “¿quién eres?”
  • Autorización responde: “¿qué puedes hacer?”

La documentación de Security Rules ayuda a ver esa diferencia. Authentication identifica al usuario y proporciona información como uid, email, firebase.sign_in_provider y claims dentro de auth.token; luego las reglas utilizan esa información para decidir qué rutas puede leer o escribir.[cite:2]

Esto significa que Firebase Authentication no reemplaza las reglas de acceso. Las habilita.

Identidad digital

La identidad digital es la representación verificable de un usuario dentro de un sistema. En Firebase Authentication, esa identidad se articula principalmente alrededor de un uid único por proyecto, atributos básicos del usuario y metadatos asociados al proveedor de inicio de sesión.[cite:2]

La documentación de Security Rules detalla que el contexto autenticado expone datos como:

  • uid, identificador único del usuario;
  • email, si existe;
  • phone_number, si existe;
  • name, si se ha configurado;
  • firebase.identities, conjunto de identidades vinculadas;
  • firebase.sign_in_provider, proveedor usado para iniciar sesión.[cite:2]

Esta identidad digital no es solamente un registro de perfil. Es la base sobre la que la aplicación decide acceso, personaliza interfaces, segmenta datos y mantiene trazabilidad.

Usuarios

En Firebase Authentication, un usuario es una identidad administrada por el servicio. Esa identidad puede haberse creado mediante correo y contraseña, un proveedor federado, teléfono, autenticación anónima o un mecanismo personalizado. Aunque en este capítulo no se implementarán proveedores concretos, es importante comprender que Firebase gestiona al usuario como entidad del sistema de identidad, no como un simple documento de Firestore.

Esta distinción es clave en el proyecto del libro. Un administrador, un docente o un alumno no deben entenderse solo como documentos en usuarios. Primero son identidades autenticables. Después, esas identidades pueden vincularse a perfiles de dominio en Firestore con roles, instituciones, grupos y permisos de negocio.

Credenciales

Las credenciales son los elementos que permiten demostrar identidad. En un sistema moderno pueden ser contraseñas, códigos de verificación, credenciales federadas provenientes de otro proveedor o tokens firmados por un backend.

Firebase Authentication administra la verificación de esas credenciales y, una vez validada la identidad, establece una sesión autenticada. En otras palabras, el usuario no “entra” a Firestore o a Storage directamente con una contraseña; primero obtiene una identidad validada por Firebase Authentication y luego el ecosistema utiliza esa identidad como base de acceso.

Sesiones

Una sesión es el estado mediante el cual la aplicación recuerda que el usuario ya fue autenticado. No basta con verificar credenciales una sola vez; el sistema necesita conservar ese resultado para que el usuario no tenga que volver a autenticarse en cada interacción.

La documentación oficial sobre persistencia de sesión en web explica que el SDK permite tres modos:

  • local, que persiste incluso después de cerrar el navegador;
  • session, que dura mientras la pestaña o ventana permanezca abierta;
  • none, que conserva el estado solo en memoria y se pierde al refrescar o cerrar.[cite:1]

Además, la documentación aclara que en aplicaciones web el comportamiento por defecto es local, siempre que el navegador lo soporte.[cite:1] Esta decisión mejora la experiencia de usuario, aunque en aplicaciones sensibles o compartidas puede ser preferible session o none.

Tokens

Los tokens son piezas de información firmada o emitida por un sistema de identidad que representan hechos sobre una autenticación. En arquitecturas modernas, los tokens permiten que distintos componentes del sistema confíen en la identidad del usuario sin reenviar constantemente credenciales primarias como la contraseña.

En Firebase Authentication, los tokens cumplen un papel central en el ciclo de vida del usuario autenticado. Aunque el usuario inicia sesión con un método concreto, el ecosistema trabaja posteriormente con tokens para mantener la sesión, validar identidad y transmitir atributos útiles a reglas y backends.[cite:2]

JWT (introducción)

JWT significa JSON Web Token. Es un formato estándar para representar claims o afirmaciones sobre una identidad en una estructura compacta y firmada. En términos didácticos, un JWT es como un “sobre firmado” que dice quién es el usuario y ciertos atributos asociados, de forma que otros componentes puedan verificar su validez.

En el contexto de Firebase Authentication, el lector debe quedarse con una idea básica por ahora: un token no es una contraseña ni una sesión de servidor tradicional. Es una representación de identidad que puede ser emitida, expirada, renovada y validada por distintos componentes.

ID Token

El ID Token es el token que representa la identidad autenticada del usuario dentro del ecosistema Firebase. La documentación de Security Rules muestra que, una vez autenticado, el contexto auth.token incluye información relevante como correo, proveedor, identidades vinculadas y claims personalizadas.[cite:2] Ese contexto existe precisamente porque la identidad del usuario llega encapsulada y validada en el token usado por los servicios.

Desde el punto de vista conceptual, el ID Token es el puente entre el acto de autenticarse y el acto de autorizar acceso dentro de Firebase. Sin ese token, Firestore Rules o Storage Rules no sabrían quién está haciendo la solicitud.

Refresh Token

El Refresh Token permite renovar la autenticación sin pedir al usuario que vuelva a introducir sus credenciales cada vez que expira el token de identidad. Aunque el capítulo no profundiza aún en la implementación detallada, sí debe dejar clara la idea arquitectónica: la sesión moderna no depende de un único token estático, sino de un ciclo donde un token de identidad se renueva mientras la sesión siga siendo válida.

La documentación de persistencia muestra que la sesión puede mantenerse localmente y sobrevivir al cierre del navegador según la estrategia elegida.[cite:1] Para que esa experiencia sea viable, el sistema necesita mecanismos de renovación y continuidad, no solo un token efímero aislado.

Access Token

En arquitectura general, un Access Token es el token que un cliente presenta para acceder a recursos protegidos. En el ecosistema Firebase y Google Cloud, el término puede aparecer en contextos distintos según el proveedor o la integración, pero para este capítulo basta con comprender la diferencia conceptual:

  • el ID Token identifica al usuario autenticado;
  • el Refresh Token ayuda a renovar la sesión;
  • un Access Token se usa para acceder a recursos o APIs protegidas según el contexto.

Esta distinción evita confusiones tempranas, especialmente cuando el lector empiece a integrar Authentication con backends propios o servicios Google adicionales.

¿Qué es Firebase Authentication?

Firebase Authentication es el servicio de Firebase encargado de gestionar la identidad de los usuarios de una aplicación. Proporciona infraestructura para autenticación, administración de sesión, emisión de tokens y exposición del estado autenticado al resto del ecosistema Firebase.

Su valor principal no radica solo en “permitir logins”, sino en resolver de forma administrada una capa muy delicada de la arquitectura: identidad digital. Sin este servicio, el equipo tendría que construir por su cuenta almacenamiento seguro de credenciales, recuperación de sesión, renovación de tokens, integración con proveedores externos y acoplamiento con reglas de acceso.

Arquitectura del servicio

A nivel conceptual, la arquitectura de Firebase Authentication incluye varios elementos:

  • la aplicación cliente;
  • el SDK de Firebase Auth;
  • el servicio administrado de autenticación;
  • los proveedores de identidad o credenciales;
  • la sesión local del usuario;
  • los tokens emitidos tras la autenticación;
  • el consumo posterior de esa identidad por Firestore, Storage, Functions y Security Rules.[cite:1][cite:2]

La autenticación no termina cuando el usuario “entra”. A partir de ese momento, el SDK mantiene el estado de autenticación, gestiona persistencia según la estrategia elegida y pone a disposición del resto del sistema la identidad del usuario.

Relación con Google Identity Platform

Firebase Authentication no vive aislado. Está estrechamente relacionado con Google Identity Platform, que es la base de identidad administrada sobre la que Google ofrece capacidades más amplias de autenticación e identidad. Para el lector de este manual, lo importante es entender que Firebase Authentication forma parte de una familia tecnológica más amplia de servicios de identidad de Google.

Esta relación explica por qué Firebase Authentication ofrece una experiencia tan integrada con proveedores modernos, tokens, claims y seguridad administrada. También ayuda a entender que el servicio no es una funcionalidad “menor” de Firebase, sino una capa profesional de identidad pensada para aplicaciones reales.

Flujo general de autenticación

De forma conceptual, el flujo general es este:

  1. El usuario abre la aplicación.
  2. La aplicación determina si existe un estado autenticado persistido.
  3. Si no existe, el usuario se autentica con un método permitido.
  4. Firebase Authentication valida la identidad y emite el estado autenticado.
  5. El SDK conserva la sesión con la persistencia configurada.[cite:1]
  6. Los servicios de Firebase reciben el contexto autenticado y lo usan para aplicar reglas o lógica de acceso.[cite:2]

Este flujo es importante porque demuestra que Authentication no es un módulo aislado de la interfaz de login. Es el punto de entrada operativo al sistema.

Integración con Firestore

Firestore y Authentication están profundamente vinculados a través de Security Rules. La documentación oficial muestra un patrón básico donde las reglas permiten lectura y escritura únicamente si request.auth.uid coincide con el identificador del documento solicitado.[cite:2]

Eso significa que Firestore no “consulta a Auth” en tiempo real como una API separada cada vez. Recibe el contexto autenticado del usuario y lo expone en reglas mediante request.auth o auth, según el servicio. La consecuencia arquitectónica es poderosa: el control de acceso puede basarse en identidad sin que el frontend tenga que decidirlo todo por su cuenta.

En el proyecto del libro, esto será fundamental. El documento de perfil de un alumno, un docente o un administrador deberá vincularse consistentemente con el uid del usuario autenticado para que las reglas puedan expresar acceso seguro y simple.

Integración con Cloud Functions

Aunque este capítulo no implementará funciones, conceptualmente Authentication también se integra con Cloud Functions porque la identidad del usuario puede ser validada o enriquecida del lado servidor. Además, ciertos procesos como asignación de claims personalizados o automatización posterior al registro suelen ocurrir en backend seguro.

Esta integración es clave para separar autenticación de lógica sensible. Por ejemplo, un usuario puede autenticarse como docente, pero la asignación del rol institucional real no debería depender solo de lo que el cliente diga de sí mismo. Cloud Functions y el Admin SDK permiten construir esa capa de confianza adicional.

Integración con Security Rules

La integración con Security Rules es una de las razones por las que Firebase Authentication resulta tan valioso dentro de Firebase. La documentación explica que las reglas tienen acceso a auth.uid, a auth.token y a claims personalizadas para implementar control basado en identidad, atributos o roles.[cite:2]

Algunos datos relevantes expuestos en auth.token son:

  • correo;
  • verificación de correo;
  • teléfono;
  • nombre;
  • proveedor de inicio de sesión;
  • identidades vinculadas;
  • claims personalizadas.[cite:2]

Esto permite que la autorización se exprese en reglas con mucha precisión. Sin Authentication, ese contexto no existiría.

Integración con Storage

La misma documentación de Security Rules muestra que Cloud Storage también puede usar request.auth.uid o claims para decidir quién puede subir archivos y a qué rutas.[cite:2] Esto es especialmente útil en el proyecto del libro, donde docentes y alumnos manejarán evidencias, archivos, materiales y documentos institucionales.

De nuevo, la identidad autenticada no es una conveniencia cosmética: es la base del control de acceso transversal a múltiples servicios.

Ciclo de vida de un usuario autenticado

El ciclo de vida de un usuario autenticado no se limita al momento del login. Incluye varias etapas:

  • creación o descubrimiento de la identidad;
  • autenticación inicial;
  • emisión del contexto autenticado;
  • persistencia de sesión según estrategia elegida;[cite:1]
  • renovación y continuidad de la identidad en el tiempo;
  • uso del contexto autenticado por reglas y servicios;[cite:2]
  • cierre explícito de sesión o pérdida del estado persistido.

Comprender este ciclo es esencial para diseñar interfaces coherentes. La aplicación debe saber cuándo mostrar pantalla de acceso, cuándo reconstruir una sesión previa, cuándo degradar privilegios y cuándo forzar reautenticación en contextos sensibles.

Estados de autenticación

En una aplicación real, el usuario no está solo en dos estados —dentro o fuera—. En realidad, la UI suele atravesar varios estados:

  • autenticación desconocida mientras se resuelve la sesión persistida;
  • usuario no autenticado;
  • usuario autenticado;
  • usuario autenticado pero todavía sin perfil de dominio cargado en Firestore;
  • usuario autenticado con sesión persistida pero con permisos aún por evaluar.

Esta distinción es crítica para el proyecto del libro. Un uid autenticado no bastará por sí mismo; la aplicación también necesitará saber si ese usuario es administrador, docente, alumno, personal de apoyo o invitado, y cómo se traduce eso en módulos habilitados.

Persistencia de sesión

La persistencia de sesión merece una explicación especial porque afecta seguridad, experiencia de usuario y arquitectura de frontend. La documentación oficial especifica tres modos en web:[cite:1]

  • local: persiste incluso al cerrar el navegador;
  • session: persiste solo en la pestaña o ventana actual;
  • none: solo memoria, se pierde al refrescar.

También indica comportamientos relevantes entre pestañas: por ejemplo, una autenticación con persistencia local puede sincronizarse entre pestañas del mismo origen, mientras que session o none permiten usuarios distintos en pestañas distintas.[cite:1]

Esta decisión tendrá impacto real en el proyecto del libro. Un sistema escolar usado en equipos personales puede beneficiarse de local; uno utilizado en equipos compartidos de biblioteca o laboratorio quizá deba preferir session.

Casos de uso reales

Firebase Authentication resulta útil en prácticamente cualquier aplicación con identidad de usuario. En el proyecto del libro aparecerá como punto de entrada para varios perfiles:

  • Administradores: gestión institucional, paneles globales y configuración del sistema.
  • Docentes: gestión de grupos, clases, tareas y asistencias.
  • Alumnos: acceso a cursos, tareas, evidencias y notificaciones.
  • Personal de apoyo: operación administrativa limitada a ciertos módulos.
  • Invitados: acceso parcial o temporal a funcionalidades muy acotadas.

En todos estos casos, Authentication cumple una misma función base: establecer quién es el usuario antes de decidir qué puede hacer.

Ventajas

Firebase Authentication ofrece ventajas especialmente fuertes en el contexto Firebase:

  • servicio administrado, sin necesidad de construir toda la infraestructura de identidad desde cero;
  • integración nativa con Security Rules, Firestore y Storage.[cite:2]
  • persistencia de sesión configurable desde el SDK web.[cite:1]
  • exposición uniforme del contexto autenticado para autorización basada en uid o claims.[cite:2]
  • alineación con una plataforma de identidad madura del ecosistema Google.

Desde el punto de vista arquitectónico, su mayor ventaja es reducir complejidad en un área extremadamente sensible del sistema.

Limitaciones

También existen limitaciones y consideraciones importantes:

  • autenticación no equivale a autorización; todavía hacen falta reglas y diseño de acceso correcto.[cite:2]
  • el uid por sí solo no modela todo el dominio; normalmente habrá que vincularlo con perfiles de Firestore.
  • la elección incorrecta de persistencia puede crear riesgos en equipos compartidos o experiencia deficiente en sesiones sensibles.[cite:1]
  • una mala estrategia de claims o perfiles puede complicar la evolución del sistema.

En otras palabras, Firebase Authentication resuelve la identidad, pero no sustituye la arquitectura de seguridad completa.

Casos reales

Caso 1: administrador institucional

Un administrador inicia sesión y accede al panel central del sistema escolar. Authentication valida su identidad y la aplicación recupera desde Firestore el perfil asociado a ese uid para habilitar módulos de administración. Las Security Rules pueden apoyarse en request.auth y en claims o perfiles institucionales para impedir que un usuario no autorizado acceda a recursos reservados.[cite:2]

Caso 2: docente

Un docente inicia sesión desde su dispositivo personal. La sesión se mantiene persistida con estrategia local para no exigir autenticación constante cada vez que consulta grupos o tareas.[cite:1] Después, la app resuelve su perfil institucional y habilita acceso a cursos, clases, asistencia y evaluación.

Caso 3: alumno

Un alumno accede a la aplicación para revisar tareas, subir evidencias y consultar notificaciones. Authentication lo identifica; Firestore y Storage aplican reglas basadas en ese contexto para permitirle solo el acceso a sus propios recursos o a los materiales de los grupos donde participa.[cite:2]

Caso 4: equipo compartido

En un laboratorio escolar o biblioteca, persistir la sesión indefinidamente puede ser un riesgo. En ese escenario, una estrategia session o incluso none puede ser más adecuada para que la identidad no sobreviva al cierre de la pestaña o al refresco del navegador.[cite:1]

Buenas prácticas

  • Separar claramente autenticación y autorización desde el diseño conceptual.
  • Vincular siempre el uid autenticado con un perfil de dominio en Firestore cuando la aplicación necesite roles, institución o datos extendidos.
  • Diseñar la persistencia de sesión según el contexto real de uso del dispositivo; no asumir que local siempre es la mejor opción.[cite:1]
  • Usar Security Rules como capa principal de control de acceso para Firestore y Storage, aprovechando request.auth y auth.token.[cite:2]
  • Utilizar claims personalizadas o perfiles controlados por backend para roles sensibles, en lugar de confiar ciegamente en datos enviados por el cliente.[cite:2]
  • Diseñar la experiencia de autenticación considerando el estado intermedio mientras se resuelve la sesión persistida.
  • Pensar Authentication como parte de la arquitectura completa del sistema y no como una simple pantalla de login.

Errores comunes

  • Confundir autenticación con autorización.
  • Pensar que un usuario autenticado ya tiene permiso automático para todo.
  • Usar solo el frontend para decidir roles críticos.
  • No vincular el uid con un perfil de dominio y terminar duplicando identidades en Firestore.
  • Elegir persistencia local en equipos compartidos sin considerar riesgos.[cite:1]
  • Olvidar que Firestore y Storage dependen de Security Rules para hacer cumplir acceso real, no solo de lo que oculte la interfaz.[cite:2]
  • Modelar administradores, docentes y alumnos como simples textos de rol sin una estrategia coherente de identidad y autorización.

Resumen

Firebase Authentication es la capa de identidad del ecosistema Firebase. Su función principal no es solamente permitir inicios de sesión, sino administrar usuarios, sesiones y contexto autenticado para que el resto de la plataforma pueda tomar decisiones seguras basadas en identidad.[cite:1][cite:2]

El servicio permite comprender la autenticación como un ciclo completo: validación inicial de credenciales, establecimiento de identidad digital, persistencia de sesión según el contexto de uso, renovación de tokens y exposición del estado autenticado a Firestore, Storage, Functions y Security Rules.[cite:1][cite:2] Esta visión es la que convierte a Authentication en un componente arquitectónico y no solo en una utilidad de interfaz.

A partir de este capítulo, el lector ya debería distinguir autenticación de autorización, entender el papel de uid, sesiones, tokens e integración con reglas, y visualizar cómo administradores, docentes, alumnos, personal de apoyo e invitados entrarán al proyecto del libro a través de Firebase Authentication. Esa base conceptual permitirá implementar en los siguientes capítulos métodos concretos de autenticación con criterio profesional.

Conceptos clave

  • Autenticación.
  • Autorización.
  • Identidad digital.
  • Usuario autenticado.
  • Credenciales.
  • Sesión.
  • Persistencia local, session, none.[cite:1]
  • Token.
  • JWT.
  • ID Token.
  • Refresh Token.
  • Access Token.
  • uid de Firebase.[cite:2]
  • auth.token.[cite:2]
  • Claims personalizadas.[cite:2]
  • Security Rules y Authentication.[cite:2]
  • Firebase Authentication.
  • Google Identity Platform.

Preguntas de repaso

  1. ¿Qué diferencia esencial existe entre autenticación y autorización?
  2. ¿Qué papel cumple la identidad digital dentro de una aplicación moderna?
  3. ¿Por qué una sesión es más que un simple “usuario conectado”?
  4. ¿Qué diferencias conceptuales hay entre ID Token, Refresh Token y Access Token?
  5. ¿Qué información relevante expone Firebase Authentication en auth.token para las reglas?[cite:2]
  6. ¿Por qué Security Rules y Authentication forman una combinación central en Firebase?[cite:2]
  7. ¿Qué ventajas y riesgos tienen las distintas estrategias de persistencia de sesión en web?[cite:1]
  8. ¿Por qué el uid autenticado debe relacionarse con un perfil de dominio dentro del proyecto del libro?
  9. ¿En qué casos conviene mover decisiones sensibles de roles o privilegios a backend seguro?
  10. ¿Por qué Firebase Authentication debe considerarse parte de la arquitectura y no solo de la interfaz de login?

Ejercicios prácticos

  1. Redacta un flujo conceptual de autenticación para un alumno desde que abre la aplicación hasta que accede a sus tareas.
  2. Diseña un esquema de integración entre Authentication y Firestore para representar administradores, docentes, alumnos, personal de apoyo e invitados.
  3. Analiza qué modo de persistencia elegirías para una app usada en equipos personales y cuál elegirías para equipos compartidos, justificando la decisión con base en la documentación.[cite:1]
  4. Propón un modelo de autorización basado en uid y claims para restringir la edición de recursos administrativos.[cite:2]
  5. Explica con tus propias palabras por qué un usuario autenticado no debería considerarse automáticamente autorizado.
  6. Diseña un flujo conceptual donde Cloud Functions participe en la asignación segura de roles después del registro inicial.
  7. Describe cómo usarías Security Rules para que un alumno solo pueda leer sus propios documentos y un docente solo los de sus grupos.[cite:2]
  8. Enumera los riesgos de depender exclusivamente del frontend para decidir privilegios de acceso.

Bibliografía y referencias oficiales