Usuarios de Identity Platform en proyectos

El objeto user de Identity Platform representa una cuenta de usuario que se ha registrado en una aplicación de tu proyecto Google Cloud. Las aplicaciones suelen tener muchos usuarios registrados y cada aplicación de un proyecto comparte una base de datos de usuarios. Google Cloud

Las instancias de usuario son independientes de las instancias de Identity Platform, por lo que puede tener varias referencias a diferentes usuarios en el mismo contexto y seguir llamando a cualquiera de sus métodos.

Propiedades de usuario

Los usuarios de Identity Platform tienen un conjunto fijo de propiedades básicas (un ID único, una dirección de correo principal, un nombre y una URL de foto) almacenadas en la base de datos de usuarios del proyecto, que pueden actualizar (iOS, Android y web). No puedes añadir otras propiedades al objeto de usuario directamente. En su lugar, puedes almacenar las propiedades adicionales en cualquier otro servicio de almacenamiento, como Google Cloud Firestore.

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

  • Si el usuario se ha registrado con una dirección de correo y una contraseña, solo se rellenará la propiedad de dirección de correo principal.
  • Si el usuario se ha registrado con un proveedor de identidades federadas, como Google o Facebook, la información de la cuenta que haya proporcionado el proveedor se utiliza para rellenar el perfil del usuario.
  • Si el usuario se ha registrado con tu sistema de autenticación personalizado, debes añadir explícitamente la información que quieras al perfil del usuario.

Una vez que se haya creado una cuenta de usuario, puedes volver a cargar la información del usuario para incorporar los cambios que haya hecho en otro dispositivo.

Proveedores de inicio de sesión

Puedes permitir que los usuarios inicien sesión en tus aplicaciones de varias formas: con una dirección de correo y una contraseña, con proveedores de identidades federadas y con tu sistema de autenticación personalizado. Puedes asociar más de un método de inicio de sesión a un usuario. Por ejemplo, un usuario puede iniciar sesión en la misma cuenta con una dirección de correo y una contraseña, o con la función Inicio de sesión con Google.

Las instancias de usuario registran todos los proveedores vinculados al usuario. De esta forma, puedes actualizar las propiedades de un perfil vacío con la información proporcionada por un proveedor. Consulta el artículo sobre cómo gestionar usuarios (iOS, Android y web).

El usuario actual

Cuando un usuario se registra o inicia sesión, se convierte en el usuario actual de la instancia Auth. La instancia conserva el estado del usuario, de modo que, si 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 cierra sesión, la instancia de Auth deja de mantener una referencia al objeto de usuario y ya no conserva su estado. Por lo tanto, no hay ningún usuario actual. Sin embargo, la instancia del usuario sigue siendo completamente funcional: si conservas una referencia a ella, podrás seguir accediendo a los datos del usuario y actualizándolos.

El ciclo de vida del usuario

La forma recomendada de monitorizar el estado actual de la instancia Auth es usar listeners (también llamados "observadores" en JavaScript). Un procesador de Auth recibe una notificación cada vez que ocurre algo relevante en el objeto Auth. Consulta el artículo sobre cómo gestionar usuarios (iOS, Android y web).

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

  • El objeto Auth termina de inicializarse y un usuario ya ha iniciado sesión en una sesión anterior o se le ha redirigido desde el flujo de inicio de sesión de un proveedor de identidades.
  • Un usuario inicia sesión (se define el usuario actual)
  • Un usuario cierra sesión (el usuario actual se convierte en nulo)
  • Se actualiza el token de acceso del usuario actual. Este caso puede darse en las siguientes condiciones:
    • El token de acceso caduca: esta es una situación habitual. El token de actualización se usa para obtener un nuevo conjunto de tokens válidos.
    • El usuario cambia su contraseña: Identity Platform emite nuevos tokens de acceso y de actualización, y hace que los tokens antiguos caduquen. De esta forma, el token del usuario caduca automáticamente o se cierra la sesión del usuario en todos los dispositivos por motivos de seguridad.
    • El usuario vuelve a autenticarse: algunas acciones requieren que las credenciales del usuario se hayan emitido recientemente. Entre estas acciones se incluyen eliminar una cuenta, establecer una dirección de correo principal y cambiar una contraseña. En lugar de cerrar la sesión del usuario y volver a iniciarla, obtén nuevas credenciales del usuario y pásalas al método reauthenticate del objeto de usuario.

Autoservicio para usuarios

De forma predeterminada, Identity Platform permite a los usuarios registrarse y eliminar sus cuentas sin intervención administrativa. En muchas circunstancias, esto permite que los usuarios finales descubran tu aplicación o servicio y que se incorporen (o se den de baja) con la mínima fricción posible.

Sin embargo, hay situaciones en las que quieres que un administrador cree usuarios manualmente o mediante programación, ya sea con el SDK de administrador o con laGoogle Cloud consola. En estos casos, puedes inhabilitar las acciones de usuario desde la página de configuración de Identity Platform, lo que impide que un usuario final cree y elimine cuentas. Si usas la arquitectura multiempresa, debes enviar una solicitud HTTP para inhabilitar estas funciones en cada empresa.

Si un usuario final intenta crear o eliminar una cuenta en tu sistema, el servicio Identity Platform devolverá un código de error: auth/admin-restricted-operation para las llamadas a la API Web o ERROR_ADMIN_RESTRICTED_OPERATION para Android y iOS. Debes gestionar el error correctamente en tu frontend pidiendo al usuario que realice las acciones adecuadas para tu servicio.

Tokens de autenticación

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

Tokens de ID de Identity Platform Identity Platform los crea cuando un usuario inicia sesión en una aplicación. Estos tokens son JWTs firmados que identifican de forma segura a un usuario en un proyecto de Google Cloud. Estos tokens contienen información básica del perfil de un usuario, incluida la cadena de ID del usuario, que es única para el proyecto Google Cloud. Como se puede verificar la integridad de los tokens de ID, puedes enviarlos a un servidor backend para identificar al usuario que tiene la sesión iniciada.
Tokens de proveedor de identidades Creadas por proveedores de identidades federadas, como Google y Facebook. Estos tokens pueden tener diferentes formatos, pero a menudo son tokens de acceso de OAuth 2.0. Las aplicaciones usan estos tokens para verificar que los usuarios se han autenticado correctamente con el proveedor de identidades y, a continuación, los convierten en credenciales que pueden usar los servicios de Identity Platform.
Tokens personalizados de Identity Platform Creada por tu sistema de autenticación personalizado para permitir que los usuarios inicien sesión en una aplicación mediante tu sistema de autenticación. Los tokens personalizados son JWTs firmados con la clave privada de una cuenta de servicio. Las aplicaciones usan estos tokens de forma muy similar a los tokens devueltos por los proveedores de identidades federadas.

Direcciones de correo verificadas

Identity Platform considera que un correo se ha verificado si cumple dos condiciones:

  1. El usuario completa el flujo de verificación de Identity Platform
  2. El correo se verifica mediante un proveedor de identidades (IdP) de confianza.

No se confía en los proveedores de identidades que verifican el correo una vez, pero permiten que los usuarios cambien las direcciones de correo sin volver a verificarlo. Se consideran de confianza los proveedores de identidades 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 verificada, ya que las cuentas siempre se verifican y se autentican con autenticación multifactor)

Proveedores no fiables:

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

En algunos casos, Identity Platform vinculará automáticamente las cuentas cuando un usuario inicie sesión con distintos proveedores usando la misma dirección de correo electrónico. Sin embargo, esto solo puede ocurrir si se cumplen determinados criterios. Para entender por qué, considera la siguiente situación: un usuario inicia sesión con Google con una cuenta @gmail.com y un agente malintencionado crea una cuenta con la misma dirección @gmail.com, pero inicia sesión a través de Facebook. Si estas dos cuentas se vincularan automáticamente, el agente malicioso obtendría acceso a la cuenta del usuario.

En los siguientes casos se describe cuándo vinculamos automáticamente las cuentas y cuándo se produce un error que requiere que el usuario o el desarrollador realicen alguna acción:

  • El usuario inicia sesión con un proveedor que no es de confianza y, a continuación, inicia sesión con otro proveedor que tampoco es de confianza con el mismo correo (por ejemplo, Facebook y, después, GitHub). Se produce un error que requiere la vinculación de cuentas.
  • El usuario inicia sesión con un proveedor de confianza y, a continuación, con un proveedor que no es de confianza con el mismo correo (por ejemplo, Google y, después, Facebook). Se produce un error que requiere la vinculación de cuentas.
  • El usuario inicia sesión con un proveedor no de confianza y, después, con un proveedor de confianza con el mismo correo (por ejemplo, Facebook y, después, Google). El proveedor de confianza sobrescribe al proveedor que no es de confianza. Si el usuario intenta iniciar sesión de nuevo con Facebook, se producirá un error que requerirá la vinculación de la cuenta.
  • El usuario inicia sesión con un proveedor de confianza y, después, con otro proveedor de confianza diferente con el mismo correo electrónico (por ejemplo, Apple y, después, Google). Ambos proveedores se vincularán sin errores.

Puedes marcar manualmente un correo como verificado mediante el SDK de administrador, pero te recomendamos que solo lo hagas si sabes que el usuario es el propietario del correo.