Saltar al contenido principal

Estructura de datos del usuario

Los usuarios son las entidades centrales en el servicio de identidad. En Logto, incluyen datos básicos de autenticación basados en el protocolo OpenID Connect, junto con datos personalizados.

Perfil del usuario

Cada usuario tiene un perfil que contiene toda la información del usuario.

Consiste en los siguientes tipos de datos:

  • Datos básicos: es la información básica del perfil del usuario. Almacena todas las demás propiedades del usuario excepto las identidades sociales y custom_data, como el id del usuario, nombre de usuario, correo electrónico, número de teléfono y cuándo fue la última vez que el usuario inició sesión.
  • Identidades sociales: almacena la información del usuario obtenida del inicio de sesión social (es decir, inicio de sesión con un conector social), como Facebook, GitHub y WeChat.
  • Datos personalizados: almacena información adicional del usuario no listada en las propiedades predefinidas del usuario, como el color y el idioma preferidos por el usuario.

Aquí tienes un ejemplo de los datos de un usuario que se obtienen de un inicio de sesión en Facebook:

{
"id": "iHXPuSb9eMzt",
"username": null,
"primaryEmail": null,
"primaryPhone": null,
"name": "John Doe",
"avatar": "https://example.com/avatar.png",
"customData": {
"preferences": {
"language": "en",
"color": "#f236c9"
}
},
"identities": {
"facebook": {
"userId": "106077000000000",
"details": {
"id": "106077000000000",
"name": "John Doe",
"email": "[email protected]",
"avatar": "https://example.com/avatar.png"
}
}
},
"lastSignInAt": 1655799453171,
"applicationId": "admin_console"
}

Puedes consultar el perfil del usuario usando Logto Console o Logto Management API, como GET /api/users/:userId.

Datos básicos

Vamos a recorrer todas las propiedades de los datos básicos del usuario.

id

id es una clave única generada automáticamente para identificar al usuario en Logto.

username

username se utiliza para iniciar sesión con username y contraseña.

Su valor proviene del nombre de usuario con el que el usuario se registró por primera vez. Puede ser null. Su valor no nulo no debe tener más de 128 caracteres, solo contener letras, números y guiones bajos (_), y NO comenzar con un número. Es sensible a mayúsculas y minúsculas.

primary_email

primary_email es la dirección de correo electrónico del usuario, utilizada para iniciar sesión con el correo electrónico y la contraseña / código de verificación.

Su valor generalmente proviene de la dirección de correo electrónico con la que el usuario se registró por primera vez. Puede ser null. Su longitud máxima es de 128.

primary_phone

primary_phone es el número de teléfono del usuario, utilizado para iniciar sesión con el número de teléfono y la contraseña / código de verificación de SMS.

Su valor generalmente proviene del número de teléfono con el que el usuario se registró por primera vez. Puede ser null. Su valor no nulo debe contener números precedidos por el código de llamada del país (excluyendo el signo más +).

name

name es el nombre completo del usuario. Su longitud máxima es de 128.

avatar

avatar es la URL que apunta a la imagen del avatar del usuario. Su longitud máxima es de 2048.

Si el usuario se registra con un conector social como Google y Facebook, su valor puede obtenerse de la información del usuario social.

nota

Esta propiedad se asigna al reclamo picture en el estándar OpenID Connect.

profile

profile almacena reclamos estándar adicionales de OpenID Connect que no están incluidos en las propiedades del usuario.

Su definición de tipo se puede encontrar en este archivo. Aquí tienes una copia de la definición de tipo:

type UserProfile = Partial<{
familyName: string;
givenName: string;
middleName: string;
nickname: string;
preferredUsername: string;
profile: string;
website: string;
gender: string;
birthdate: string;
zoneinfo: string;
locale: string;
address: Partial<{
formatted: string;
streetAddress: string;
locality: string;
region: string;
postalCode: string;
country: string;
}>;
}>;
nota

Partial significa que todas las propiedades son opcionales.

Una diferencia en comparación con otros reclamos estándar es que las propiedades en profile solo se incluirán en el Token de ID o en la respuesta del endpoint userinfo cuando sus valores no estén vacíos, mientras que otros reclamos estándar devolverán null si los valores están vacíos.

application_id

El valor de application_id proviene de la aplicación en la que el usuario inició sesión por primera vez. Puede ser null.

last_signed_in_at

last_signed_in_at es la marca de tiempo con la zona horaria cuando el usuario inició sesión por última vez.

password_encrypted

password_encrypted se utiliza para almacenar la contraseña encriptada del usuario.

Su valor proviene de la contraseña con la que el usuario se registró por primera vez. Puede ser null. Si su valor no es nulo, su contenido original antes de la encriptación debe tener al menos seis caracteres.

password_encryption_method

password_encryption_method se utiliza para encriptar la contraseña del usuario. Su valor se inicializa cuando el usuario se registra con el nombre de usuario y la contraseña. Puede ser null.

Logto utiliza la implementación node-argon2 de Argon2 como método de encriptación por defecto; consulta la referencia para más detalles si estás interesado.

Ejemplo de un password_encrypted y password_encryption_method de un usuario cuya contraseña es 123456:

{
"password_encryption_method": "Argon2i",
"password_encrypted": "$argon2i$v=19$m=4096,t=10,p=1$aZzrqpSX45DOo+9uEW6XVw$O4MdirF0mtuWWWz68eyNAt2u1FzzV3m3g00oIxmEr0U"
}

is_suspended

is_suspended es un valor booleano que indica si un usuario está suspendido o no. El valor se puede gestionar llamando a la Logto Management API o utilizando Logto Console.

Una vez que un usuario está suspendido, los tokens de actualización pre-otorgados se revocarán inmediatamente y el usuario no podrá ser autenticado por Logto más.

Referencia de propiedades

Las siguientes propiedades (excepto password_encrypted y password_encryption_method) son visibles en el perfil del usuario, lo que significa que puedes consultarlas usando Management API.

NombreTipoDescripciónÚnicoRequerido
idstringIdentificador único
usernamestringNombre de usuario para iniciar sesión
primary_emailstringCorreo electrónico principal
primary_phonestringNúmero de teléfono principal
namestringNombre completo
avatarstringURL que apunta a la imagen del avatar del usuario
identitiesobjectInformación del usuario obtenida del inicio de sesión social
custom_dataobjectInformación adicional en propiedades personalizables
application_idstringID de la aplicación en la que el usuario se registró por primera vez
last_sign_in_atdate timeMarca de tiempo cuando el usuario inició sesión por última vez
password_encryptedstringContraseña encriptada
password_encryption_methodstringMétodo de encriptación de la contraseña
is_suspendedboolMarca de suspensión del usuario
  • Único: Asegura la unicidad de los valores ingresados en una propiedad de una tabla de base de datos.
  • Requerido: Asegura que los valores ingresados en una propiedad de una tabla de base de datos NO puedan ser null.

Identidades sociales

identities contiene la información del usuario obtenida del inicio de sesión social (es decir, inicio de sesión con un conector social). Cada identities de usuario se almacena en un objeto JSON individual.

La información del usuario varía según el proveedor de identidad social (es decir, plataforma de red social), y generalmente incluye lo siguiente:

  • target del proveedor de identidad, como "facebook" o "google"
  • Identificador único del usuario para este proveedor
  • Nombre del usuario
  • Correo electrónico verificado del usuario
  • Avatar del usuario

La cuenta del usuario puede estar vinculada a múltiples proveedores de identidad social a través del inicio de sesión social; la información del usuario correspondiente obtenida de estos proveedores se almacenará en el objeto identities.

Ejemplo de identities de un usuario que inició sesión con Google y Facebook:

{
"facebook": {
"userId": "5110888888888888",
"details": {
"id": "5110888888888888",
"name": "John Doe",
"email": "[email protected]",
"avatar": "https://example.com/avatar.png"
}
},
"google": {
"userId": "111000000000000000000",
"details": {
"id": "111000000000000000000",
"name": "John Doe",
"email": "[email protected]",
"avatar": "https://example.com/avatar.png"
}
}
}

Datos personalizados

custom_data almacena información adicional del usuario no listada en las propiedades predefinidas del usuario.

Puedes usar custom_data para hacer lo siguiente:

  • Registrar si se han realizado acciones específicas por parte del usuario, como haber visto la página de bienvenida.
  • Almacenar datos específicos de la aplicación en el perfil del usuario, como el idioma y la apariencia preferidos por el usuario por aplicación.
  • Mantener otros datos arbitrarios relacionados con el usuario.

Ejemplo de custom_data de un usuario administrador en Logto:

{
"adminConsolePreferences": {
"language": "en",
"appearanceMode": "system",
"experienceNoticeConfirmed": true
},
"customDataFoo": {
"foo": "foo"
},
"customDataBar": {
"bar": "bar"
}
}

Cada custom_data de usuario se almacena en un objeto JSON individual.

Nota: NO pongas datos sensibles en custom_data.

Puedes obtener un perfil de usuario que contenga custom_data usando Management API y enviarlo a las aplicaciones frontend o servicios backend externos. Por lo tanto, poner información sensible en custom_data puede causar filtraciones de datos.

Si aún deseas poner la información sensible en custom_data, recomendamos encriptarla primero. Solo encripta / desencripta en una parte confiable como tus servicios backend, y evita hacerlo en las aplicaciones frontend. Esto minimizará la pérdida si el custom_data de tus usuarios se filtra por error.

Puedes actualizar el custom_data del usuario usando Logto Console o Logto Management API, como PATCH /api/users/:userId.

Actualiza con cuidado

Actualizar el custom_data de un usuario sobrescribirá completamente su contenido original en el almacenamiento.

Por ejemplo, si tu entrada al llamar a la API de actualización de custom_data se ve así (supongamos que el custom_data original es el ejemplo de datos mostrado anteriormente):

{
"customDataBaz": {
"baz": "baz"
}
}

entonces el nuevo valor de custom_data después de la actualización debería ser:

{
"customDataBaz": {
"baz": "baz"
}
}

Es decir, el valor del campo actualizado no tiene nada que ver con el valor anterior.

Recursos relacionados

Centro seguro para datos de usuario en movimiento