Catch up on everything announced at Firebase Summit, and learn how Firebase can help you accelerate app development and run your app with confidence. Learn More

Usuarios en proyectos de Firebase

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

El objeto de usuario de Firebase representa una cuenta de usuario que se ha registrado para una aplicación en su proyecto. Las aplicaciones suelen tener muchos usuarios registrados y todas las aplicaciones de un proyecto comparten una base de datos de usuarios.

Las instancias de usuario son independientes de las instancias de autenticación de Firebase, por lo que puede tener varias referencias a diferentes usuarios dentro del mismo contexto y seguir llamando a cualquiera de sus métodos.

Propiedades de usuario

Los usuarios de Firebase tienen un conjunto fijo de propiedades básicas (una identificación única, una dirección de correo electrónico principal, un nombre y una URL de foto) almacenados en la base de datos de usuarios del proyecto, que el usuario puede actualizar ( iOS , Android , web ). No puede agregar otras propiedades al objeto de usuario directamente; en su lugar, puede almacenar las propiedades adicionales en cualquier otro servicio de almacenamiento, como Google Cloud Firestore.

La primera vez que un usuario se registra en su aplicación, los datos del perfil del usuario se completan con la información disponible:

  • Si el usuario se registró con una dirección de correo electrónico y una contraseña, solo se completa la propiedad de la dirección de correo electrónico principal.
  • Si el usuario se registró con un proveedor de identidad federado, como Google o Facebook, la información de la cuenta proporcionada por el proveedor se usa para completar el perfil del usuario.
  • Si el usuario se registró con su sistema de autenticación personalizado, debe agregar explícitamente la información que desea al perfil del usuario.

Una vez que se ha creado una cuenta de usuario, puede volver a cargar la información del usuario para incorporar cualquier cambio que el usuario haya realizado en otro dispositivo.

Proveedores de inicio de sesión

Puede iniciar la sesión de los usuarios en sus aplicaciones mediante varios métodos: dirección de correo electrónico y contraseña, proveedores de identidad federados y su sistema de autenticación personalizado. Puede asociar más de un método de inicio de sesión con un usuario: por ejemplo, un usuario puede iniciar sesión en la misma cuenta con una dirección de correo electrónico y una contraseña, o con Google Sign-In.

Las instancias de usuario realizan un seguimiento de cada proveedor vinculado al usuario. Esto le permite actualizar las propiedades del perfil vacío utilizando la información proporcionada por un proveedor. Consulte Administración de usuarios ( iOS , Android , web ).

El usuario actual

Cuando un usuario se registra o inicia sesión, ese usuario se convierte en el usuario actual de la instancia de autenticación. La instancia conserva el estado del usuario, de modo que al actualizar la página (en un navegador) o al reiniciar la aplicación no se pierde la información del usuario.

Cuando el usuario cierra la sesión, la instancia de Auth deja de mantener una referencia al objeto del usuario y ya no conserva su estado; no hay ningún usuario actual. Sin embargo, la instancia de usuario continúa siendo completamente funcional: si mantiene una referencia a ella, aún puede acceder y actualizar los datos del usuario.

El ciclo de vida del usuario

La forma recomendada de rastrear el estado actual de la instancia de Auth es mediante el uso de oyentes (también llamados "observadores" en JavaScript). Un oyente de autenticación recibe una notificación cada vez que sucede algo relevante con el objeto de autenticación. Consulte Administración de usuarios ( iOS , Android , web ).

Un oyente de Auth recibe una notificación en las siguientes situaciones:

  • El objeto Auth termina de inicializarse y un usuario ya inició sesión desde una sesión anterior, o ha sido redirigido desde el flujo de inicio de sesión de un proveedor de identidad
  • Un usuario inicia sesión (se establece el usuario actual)
  • Un usuario cierra la sesión (el usuario actual se vuelve nulo)
  • El token de acceso del usuario actual se actualiza. Este caso puede ocurrir en las siguientes condiciones:
    • El token de acceso caduca: esta es una situación común. El token de actualización se usa para obtener un nuevo conjunto válido de tokens.
    • El usuario cambia su contraseña: Firebase emite nuevos tokens de acceso y actualización, y muestra que los tokens anteriores caducaron. Esto caduca automáticamente el token del usuario y/o cierra la sesión del usuario en todos los dispositivos, por razones de seguridad.
    • El usuario se vuelve a autenticar: algunas acciones requieren que las credenciales del usuario se hayan emitido recientemente; dichas acciones incluyen la eliminación de una cuenta, la configuración de una dirección de correo electrónico principal y el cambio de una contraseña. En lugar de cerrar la sesión del usuario y luego volver a iniciarla, obtenga nuevas credenciales del usuario y pase las nuevas credenciales al método de reautenticación del objeto de usuario.

Autoservicio del usuario

De forma predeterminada, Firebase permite a los usuarios registrarse y eliminar sus cuentas sin intervención administrativa. En muchas circunstancias, esto permite que los usuarios finales descubran su aplicación o servicio a bordo (o fuera) con una fricción mínima.

Sin embargo, hay situaciones en las que desea que un administrador cree usuarios de forma manual o programática, ya sea mediante Admin SDK o Firebase console. En estos casos, puede deshabilitar las acciones del usuario desde la página Configuración de autenticación de Firebase , lo que evita que los usuarios finales creen y eliminen cuentas. Si está utilizando multiinquilino, deberá realizar una solicitud HTTP para deshabilitar estas funciones por inquilino.

Si un usuario final intenta crear o eliminar una cuenta dentro de su sistema, el servicio Firebase devolverá un código de error: auth/admin-restricted-operation para llamadas a la API web o ERROR_ADMIN_RESTRICTED_OPERATION para Android e iOS. Debe manejar con gracia el error en su front-end pidiéndole al usuario que tome las medidas apropiadas para su servicio.

tokens de autenticación

Cuando realiza la autenticación con Firebase, hay tres tipos de tokens de autenticación que puede encontrar:

Fichas de identificación de Firebase Creado por Firebase cuando un usuario inicia sesión en una aplicación. Estos tokens son JWT firmados que identifican de forma segura a un usuario en un proyecto de Firebase. Estos tokens contienen información de perfil básica para un usuario, incluida la cadena de identificación del usuario, que es exclusiva del proyecto de Firebase. Debido a que se puede verificar la integridad de los tokens de ID , puede enviarlos a un servidor back-end para identificar al usuario que ha iniciado sesión actualmente.
Tokens de proveedor de identidad Creado por proveedores de identidad federados, como Google y Facebook. Estos tokens pueden tener diferentes formatos, pero a menudo son tokens de acceso OAuth 2.0. Las aplicaciones usan estos tokens para verificar que los usuarios se hayan autenticado correctamente con el proveedor de identidad y luego los convierten en credenciales que pueden usar los servicios de Firebase.
Fichas personalizadas de Firebase Creado por su sistema de autenticación personalizado para permitir que los usuarios inicien sesión en una aplicación utilizando su sistema de autenticación. Los tokens personalizados son JWT firmados con la clave privada de una cuenta de servicio . Las aplicaciones usan estos tokens de la misma manera que usan los tokens devueltos por los proveedores de identidades federadas.

Direcciones de correo electrónico verificadas

Firebase considera que un correo electrónico está verificado si cumple con dos condiciones: 1. El usuario completa el flujo de verificación de Firebase. 2. El correo electrónico es verificado por un proveedor de identidad de confianza, o IdP para abreviar.

Los IdP que verifican el correo electrónico una vez, pero luego permiten a los usuarios cambiar las direcciones de correo electrónico sin necesidad de volver a verificarlos, no son de confianza. Los IdP que poseen el dominio o siempre requieren verificación se consideran confiables.

Proveedores de confianza:

  • Google (para direcciones de @gmail.com)
  • Yahoo (para direcciones @yahoo.com)
  • Microsoft (para las direcciones @outlook.com y @hotmail.com)
  • Apple (siempre verificado, porque las cuentas siempre están verificadas y autenticadas por múltiples factores)

Proveedores no confiables:

  • Facebook
  • Gorjeo
  • GitHub
  • Google, Yahoo y Microsoft para dominios no emitidos por ese proveedor de identidad
  • Correo electrónico / Contraseña sin verificación de correo electrónico

En algunas situaciones, Firebase vinculará automáticamente las cuentas cuando un usuario inicie sesión con diferentes proveedores con la misma dirección de correo electrónico. Sin embargo, esto solo puede suceder cuando se cumplen criterios específicos. Para comprender por qué, considere la siguiente situación: un usuario inicia sesión con Google con una cuenta de @gmail.com y un actor malicioso crea una cuenta con la misma dirección de @gmail.com, pero inicia sesión a través de Facebook. Si estas dos cuentas se vincularan automáticamente, el actor malicioso obtendría acceso a la cuenta del usuario.

Los siguientes casos describen cuándo vinculamos cuentas automáticamente y cuándo arrojamos un error que requiere la acción del usuario o del desarrollador:

  • El usuario inicia sesión con un proveedor que no es de confianza, luego inicia sesión con otro proveedor que no es de confianza con el mismo correo electrónico (por ejemplo, Facebook seguido de GitHub). Esto arroja un error que requiere la vinculación de la cuenta.
  • El usuario inicia sesión con un proveedor de confianza, luego inicia sesión con un proveedor que no es de confianza con el mismo correo electrónico (por ejemplo, Google seguido de Facebook). Esto arroja un error que requiere la vinculación de la cuenta.
  • El usuario inicia sesión con un proveedor que no es de confianza, luego inicia sesión con un proveedor de confianza con el mismo correo electrónico (por ejemplo, Facebook seguido de Google). El proveedor de confianza sobrescribe al proveedor que no es de confianza. Si el usuario intenta iniciar sesión nuevamente con Facebook, se producirá un error que requerirá la vinculación de la cuenta.
  • El usuario inicia sesión con un proveedor de confianza, luego inicia sesión con un proveedor de confianza diferente con el mismo correo electrónico (por ejemplo, Apple seguido de Google). Ambos proveedores estarán vinculados sin errores.

Puede configurar manualmente un correo electrónico como verificado mediante el SDK de administrador, pero solo recomendamos hacerlo si sabe que el usuario realmente es el propietario del correo electrónico.