Usuarios en proyectos Firebase

Un objeto de usuario de Firebase representa la cuenta de un usuario que se registró en una app de tu proyecto. Generalmente, las apps tienen muchos usuarios registrados, y todas las apps de un proyecto comparten una base de datos de usuarios.

Las instancias de usuarios son independientes de las instancias de Firebase Authentication. Por lo tanto, pueden existir varias referencias a diferentes usuarios en el mismo contexto y llamar a cualquiera de sus métodos.

Propiedades del usuario

Los usuarios de Firebase tienen un conjunto fijo de propiedades básicas, es decir, un ID único, una dirección de correo electrónico principal, una URL de nombre y una de foto, que se almacenan en una base de datos de usuarios de un proyecto y que el usuario puede actualizar (en iOS, Android y la Web). No se pueden agregar otras propiedades al objeto de usuario directamente. En cambio, puedes almacenarlas en cualquier otro servicio de almacenamiento, como Google Cloud Firestore.

La primera vez que se registra un usuario en la app, los datos de su perfil se propagan con la información disponible:

  • Si el usuario se registró con una dirección de correo electrónico y una contraseña, solo se propaga la propiedad de dirección de correo electrónico principal.
  • Si el usuario se registró con un proveedor de identidad federada, como Google o Facebook, la información de la cuenta que entregó el proveedor se usa para propagar el perfil del usuario.
  • Si el usuario se registró con tu sistema de autenticación personalizado, debes agregar explícitamente la información que desees al perfil del usuario.

Una vez que se crea una cuenta de usuario, puedes volver a cargar la información de esa persona para incorporar los cambios que pueda haber realizado en otro dispositivo.

Proveedores de acceso

Puedes hacer que los usuarios accedan a tus apps a través de varios métodos: dirección de correo electrónico y contraseña, proveedores de identidades federadas y tu sistema de autenticación personalizado. Puedes asociar más de un método de acceso a un usuario. Por ejemplo, este puede acceder a la misma cuenta usando una dirección de correo electrónico y una contraseña, o el Acceso con Google.

Las instancias de usuarios llevan un registro de cada proveedor vinculado al usuario. Esto permite actualizar las propiedades de perfiles vacíos mediante la información que brinda un proveedor. Consulta “Administra usuarios” (para iOS, Android y la Web).

El usuario actual

Cuando un usuario se registra o accede, pasa a ser el usuario actual de la instancia de Auth. La instancia conserva el estado del usuario. Por lo tanto, cuando se actualiza la página (en un navegador) o se reinicia la aplicación, no se pierde la información del usuario.

Cuando el usuario sale de su sesión, la instancia de Auth deja de conservar una referencia al objeto de usuario y con ello el estado de este. Por consiguiente, deja de haber un usuario actual. Sin embargo, la instancia de usuario continúa siendo totalmente funcional: si conservas una referencia a ella, puedes acceder a los datos del usuario y actualizarlos.

El ciclo de vida del usuario

La forma recomendada de realizar un seguimiento del estado actual de la instancia de Auth es usar objetos de escucha (también denominados “observadores” en JavaScript). Un objeto de escucha de Auth recibe notificaciones cuando sucede algo importante en el objeto de Auth. Consulta “Administra usuarios” (para iOS, Android y la Web).

Un agente de escucha de Auth recibe notificaciones en las siguientes situaciones:

  • Cuando el objeto Auth termina de inicializarse y ya hay un usuario con sesión activa, o este mismo se ha redireccionado de un flujo de acceso de un proveedor de identidad.
  • Cuando un usuario accede a su cuenta (el usuario activo está configurado).
  • Cuando un usuario sale de su sesión (el usuario activo pasa a ser nulo).
  • Cuando se actualiza el token de acceso del usuario actual. Esto puede suceder en las siguientes condiciones:
    • Cuando el token de acceso se vence: es una situación común. El token de actualización se usa para obtener un nuevo conjunto válido de tokens.
    • Cuando el usuario cambia la contraseña: Firebase emite tokens de acceso y de actualización nuevos, y hace que caduquen los tokens antiguos. Este proceso hace que los tokens del usuario caduquen o que se cierre sesión en todos los dispositivos automáticamente, por motivos de seguridad.
    • Cuando el usuario vuelve a autenticarse: Algunas acciones, como borrar una cuenta, configurar una dirección de correo electrónico principal y cambiar una contraseña, requieren que las credenciales del usuario se hayan emitido recientemente. En vez de cerrar la sesión del usuario y volver a acceder, obtén credenciales nuevas y pásalas al método de renovación de autenticación del objeto de usuario.

Autoservicio para los usuarios

De forma predeterminada, Firebase permite que los usuarios se registren y borren sus cuentas sin intervención administrativa. En muchos casos, esto permite a los usuarios finales descubrir tu aplicación o servicio y, luego, integrarlos (o desvincularlos) con una fricción mínima.

Sin embargo, hay situaciones en las que es preferible que un administrador cree a los usuarios de forma manual o programática, ya sea mediante el SDK de Admin o Firebase console. En estos casos, puedes inhabilitar las acciones del usuario en la página de configuración de Firebase Authentication, lo que evita que los usuarios finales creen cuentas y las borren. Si usas la función multiusuario, deberás realizar una solicitud HTTP para inhabilitar estas funciones por usuario.

Si un usuario final intenta crear o borrar una cuenta dentro de tu sistema, el servicio de Firebase mostrará un código de error: auth/admin-restricted-operation para llamadas a la API web o ERROR_ADMIN_RESTRICTED_OPERATION para iOS y Android. Debes manejar correctamente el error en tu frontend y solicitarle al usuario que realice las acciones apropiadas para tu servicio.

Tokens de autenticación

Cuando realizas la autenticación con Firebase, puedes encontrar las siguientes tres clases de tokens de autenticación:

Tokens de ID de Firebase Firebase los crea cuando un usuario accede a una app. Estos tokens son JWT firmados que identifican de manera segura a un usuario en un proyecto de Firebase. Estos tokens contienen información de perfil básica de un usuario, incluida la string de ID del usuario, que es exclusiva del proyecto de Firebase. Gracias a que la integridad de los tokens de ID se puede verificar, puedes enviarlos a un servidor de backend para identificar al usuario activo.
Tokens del proveedor de identidad Se crean a través de proveedores de identidades federadas, como Google y Facebook. Estos tokens pueden tener diferentes formatos, pero frecuentemente son tokens de acceso de OAuth 2.0. Las apps los usan para verificar que los usuarios se hayan autenticado de forma correcta a través del proveedor de identidad y luego convertirlos en credenciales que puedan usarse con servicios de Firebase.
Tokens personalizados de Firebase Se crean a través de tu sistema personalizado de autenticación para permitir que los usuarios accedan a una app mediante tu sistema de autenticación. Los tokens personalizados son JWT firmados con la clave privada de una cuenta de servicio. Las apps usan estos tokens de manera muy similar a los tokens que muestran los proveedores de identidad federada.

Direcciones de correo electrónico verificadas

Firebase considera que un correo electrónico se verificó si cumple con dos condiciones:

  1. El usuario completa el flujo de verificación de Firebase.
  2. Un proveedor de identidad (IdP) confiable verifica el correo electrónico.

No se consideran confiables los IdP que verifican el correo electrónico una vez, pero luego permiten que los usuarios cambien las direcciones de correo electrónico sin requerir una nueva verificación. Se consideran confiables los IdP que son propietarios del dominio o que siempre requieren verificación.

Proveedores de confianza:

  • Google (para direcciones @gmail.com)
  • Yahoo (para direcciones @yahoo.com)
  • Microsoft (para direcciones @outlook.com y @hotmail.com)
  • Apple (siempre verificado porque siempre se verifican las cuentas y se autentican mediante varios factores)

Proveedores no confiables:

  • Facebook
  • Twitter
  • GitHub
  • Google, Yahoo y Microsoft para dominios que no emitió ese proveedor de identidad
  • Correo electrónico y contraseña sin verificación por correo electrónico

En algunas situaciones, Firebase vinculará automáticamente las cuentas cuando los usuarios accedan con proveedores distintos mediante la misma dirección de correo electrónico. Sin embargo, esto solo puede suceder cuando se cumplen criterios específicos. Para comprender por qué, considera la siguiente situación: un usuario accede mediante Google con una cuenta @gmail.com y una persona malintencionada crea una cuenta con la misma dirección @gmail.com, pero accede mediante Facebook. Si estas dos cuentas se vincularon automáticamente, la persona malintencionada obtendría acceso a la cuenta del usuario.

En los siguientes casos, se describen las situaciones en que se vinculan automáticamente las cuentas y el momento en que se muestra un error que requiere una acción del usuario o del desarrollador:

  • El usuario accede con un proveedor no confiable y, luego, accede con otro proveedor no confiable que tiene el mismo correo electrónico (por ejemplo, Facebook seguido de GitHub). Se arrojará un error para solicitar la vinculación de las cuentas.
  • El usuario accede con un proveedor confiable y, luego, accede con otro proveedor no confiable que tiene el mismo correo electrónico (por ejemplo, Google seguido de Facebook). Se arrojará un error para solicitar la vinculación de las cuentas.
  • El usuario accede con un proveedor no confiable y, luego, accede con un proveedor confiable que tiene el mismo correo electrónico (por ejemplo, Facebook seguido de Google). El proveedor de confianza reemplaza al proveedor que no es de confianza. Si el usuario intenta acceder nuevamente con Facebook, se arrojará un error para solicitar la vinculación de las cuentas.
  • El usuario accede con un proveedor confiable y, luego, accede con otro proveedor confiable que tiene el mismo correo electrónico (por ejemplo, Apple seguido de Google). Se vincularán ambos proveedores sin errores.

Puedes configurar un correo electrónico manualmente como verificado mediante el SDK de Admin. Sin embargo, te recomendamos que lo hagas solo si sabes que el usuario es realmente el propietario del correo electrónico.