El objeto de usuario de Firebase representa una cuenta de usuario que se registró en una aplicación en su proyecto. Las aplicaciones suelen tener muchos usuarios registrados y cada aplicación de un proyecto comparte una base de datos de usuarios.
Las instancias de usuario son independientes de las instancias de Firebase Authentication, por lo que puedes tener varias referencias a diferentes usuarios dentro del mismo contexto y aun así llamar 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) almacenadas 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 utiliza 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 recargar 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 sesión en sus aplicaciones utilizando 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 utilizando una dirección de correo electrónico y una contraseña, o mediante el inicio de sesión de Google.
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 Gestió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 reiniciar la aplicación no se pierde la información del usuario.
Cuando el usuario cierra sesión, la instancia de autenticación deja de mantener una referencia al objeto de usuario y ya no conserva su estado; no hay ningún usuario actual. Sin embargo, la instancia de usuario sigue 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 realizar un seguimiento del estado actual de la instancia de autenticación 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 Gestión de usuarios ( iOS , Android , web ).
Un oyente de autenticación recibe una notificación en las siguientes situaciones:
- El objeto de autenticación termina de inicializarse y un usuario ya inició sesión en 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 (el usuario actual está configurado)
- Un usuario cierra sesión (el usuario actual se vuelve nulo)
- Se actualiza el token de acceso del usuario actual. 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 utiliza 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 hace que los tokens antiguos caduquen. Esto hace caducar automáticamente el token del usuario y/o cierra la sesión del usuario en cada dispositivo, 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 eliminar una cuenta, configurar una dirección de correo electrónico principal y cambiar una contraseña. En lugar de cerrar la sesión del usuario y luego volver a iniciarla, obtenga nuevas credenciales del usuario y páselas al método de reautenticación del objeto de usuario.
Autoservicio de usuario
De forma predeterminada, Firebase permite a los usuarios registrarse y eliminar sus cuentas sin intervención administrativa. En muchas circunstancias, esto permite a los usuarios finales descubrir su aplicación o servicio e incorporarlo (o desconectarlo) con una fricción mínima.
Sin embargo, hay situaciones en las que desea que un administrador cree los usuarios de forma manual o mediante programación, ya sea mediante el SDK de administración o Firebase console. En estos casos, puede desactivar las acciones del usuario desde la página Configuración de autenticación de Firebase , lo que impide la creación y eliminación de cuentas por parte de los usuarios finales. Si utiliza 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 API web, o ERROR_ADMIN_RESTRICTED_OPERATION para Android e iOS. Debe manejar con elegancia el error en su interfaz pidiéndole al usuario que realice las acciones apropiadas para su servicio.
tokens de autenticación
Cuando realizas la autenticación con Firebase, hay tres tipos de tokens de autenticación que puedes 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 ID del usuario, que es exclusiva del proyecto de Firebase. Dado que se puede verificar la integridad de los tokens de identificación , puede enviarlos a un servidor backend para identificar al usuario que ha iniciado sesión actualmente. |
| Tokens de proveedor de identidad | Creado por proveedores de identidades federados, como Google y Facebook. Estos tokens pueden tener diferentes formatos, pero suelen ser 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 utilizar los servicios de Firebase. |
| Fichas personalizadas de Firebase | Creado por su sistema de autenticación personalizado para permitir a los usuarios iniciar 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 utilizan estos tokens de forma muy parecida a los tokens devueltos por los proveedores de identidades federados. |
Direcciones de correo electrónico verificadas
Firebase considera un correo electrónico verificado si cumple dos condiciones:
- El usuario completa el flujo de verificación de Firebase.
- El correo electrónico es verificado por un proveedor de identidad confiable, 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 requerir una nueva verificación, no son de confianza. Los IdP que poseen el dominio o que siempre requieren verificación se consideran confiables.
Proveedores de confianza:
- Google (para direcciones @gmail.com)
- Yahoo (para direcciones @yahoo.com)
- Microsoft (para direcciones @outlook.com y @hotmail.com)
- Apple (siempre verificada, porque las cuentas siempre están verificadas y autenticadas por múltiples factores)
Proveedores no confiables:
- 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 utilizando la misma dirección de correo electrónico. Sin embargo, esto sólo puede suceder cuando se cumplen ciertos criterios. Para entender por qué, considere la siguiente situación: un usuario inicia sesión usando Google con una cuenta @gmail.com y un actor malicioso crea una cuenta usando la misma dirección @gmail.com, pero iniciando sesión a través de Facebook. Si estas dos cuentas se vincularan automáticamente, el actor malintencionado 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 y 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 genera un error que requiere vincular la cuenta.
- El usuario inicia sesión con un proveedor confiable y luego inicia sesión con un proveedor que no es confiable con el mismo correo electrónico (por ejemplo, Google seguido de Facebook). Esto genera un error que requiere vincular la cuenta.
- El usuario inicia sesión con un proveedor que no es de confianza y 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 en Facebook, se producirá un error que requerirá la vinculación de la cuenta.
- El usuario inicia sesión con un proveedor de confianza y 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 recomendamos hacerlo solo si sabe que el usuario realmente es el propietario del correo electrónico.