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 ycustom_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.
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;
}>;
}>;
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.
Nombre | Tipo | Descripción | Único | Requerido |
---|---|---|---|---|
id | string | Identificador único | ✅ | ✅ |
username | string | Nombre de usuario para iniciar sesión | ✅ | ❌ |
primary_email | string | Correo electrónico principal | ✅ | ❌ |
primary_phone | string | Número de teléfono principal | ✅ | ❌ |
name | string | Nombre completo | ❌ | ❌ |
avatar | string | URL que apunta a la imagen del avatar del usuario | ❌ | ❌ |
identities | object | Información del usuario obtenida del inicio de sesión social | ❌ | ✅ |
custom_data | object | Información adicional en propiedades personalizables | ❌ | ✅ |
application_id | string | ID de la aplicación en la que el usuario se registró por primera vez | ❌ | ✅ |
last_sign_in_at | date time | Marca de tiempo cuando el usuario inició sesión por última vez | ❌ | ✅ |
password_encrypted | string | Contraseña encriptada | ❌ | ❌ |
password_encryption_method | string | Método de encriptación de la contraseña | ❌ | ❌ |
is_suspended | bool | Marca 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