Usuarios de Identity Platform en proyectos

El objeto usuario de Identity Platform representa una cuenta de usuario que se registró para obtener una app en tu proyecto de Google Cloud. Por lo general, las apps tienen muchos usuarios registrados y todas las apps de un proyecto de Google Cloud comparten una base de datos de usuarios.

Las instancias de usuarios son independientes de las instancias de Identity Platform. 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 Identity Platform tienen un conjunto fijo de propiedades básicas (un ID único, una dirección de correo electrónico principal, una URL de nombre y foto) almacenado en la base de datos de usuarios del proyecto que el usuario puede actualizar (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.
- El usuario cambia su contraseña: Identity Platform emite nuevos tokens de acceso y actualización, y renderiza los tokens antiguos que vencieron. 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.

De forma predeterminada, Identity Platform 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 deseas que un administrador cree a los usuarios de forma manual o programática, ya sea mediante el SDK de Admin o la consola de Google Cloud. En estos casos, puedes inhabilitar las acciones del usuario desde la página de configuración de Identity Platform, lo que evita que un usuario final cree o borre una cuenta. Si usas la función multiusuario, debes 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 Identity Platform 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 mediante la solicitud al usuario de que realice las acciones apropiadas para tu servicio.

Tokens de autenticación

Cuando realizas la autenticación con Identity Platform, puedes encontrar tres tipos de tokens de autenticación:

Tokens de ID de Identity Platform	Se crea mediante Identity Platform cuando un usuario accede a una app. Estos tokens son JWT firmados que identifican de manera segura a un usuario en un proyecto de Google Cloud. 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 Google Cloud. 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 Identity Platform.
Tokens personalizados de Identity Platform	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

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

El usuario completa el flujo de verificación de Identity Platform
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.