Un modelo de usuario personalizado reemplaza el User predeterminado de Django para adaptarse a las necesidades de tu aplicación — agregando campos, cambiando el identificador de inicio de sesión (por ejemplo, email en lugar de nombre de usuario), o personalizando el comportamiento. El consejo crítico y frecuentemente repetido: configura un modelo de usuario personalizado al principio de un proyecto, incluso si no necesitas cambios aún, porque modificarlo después es extremadamente difícil.
The default User has fixed fields (username, email, first/last name) and uses
USERNAME as the login field. Real apps often need:
✓ Email-based login (no username)
✓ Extra fields (phone, avatar, role, preferences) on the user itself
✓ Custom authentication behavior
⚠️ Changing the user model AFTER migrations exist is VERY hard — the User model is
referenced by auth, admin, sessions, foreign keys throughout the database.
Swapping it later requires complex, risky data migrations.
→ ALWAYS define a custom user model at project START (before the first migration),
even an empty one, so you can extend it freely later. Django's docs strongly
recommend this for EVERY new project.
Esta es la lección práctica clave: no cuesta casi nada configurar un modelo de usuario personalizado en el primer día, pero adaptar uno a un proyecto establecido es una tarea importante y propensa a errores — por eso lo haces desde el principio como seguro.
# models.py — add fields, keep Django's auth behavior
from django.contrib.auth.models import AbstractUser
class User(AbstractUser):
phone = models.CharField(max_length=20, blank=True)
avatar = models.ImageField(upload_to="avatars/", blank=True)
is_premium = models.BooleanField(default=False)
# settings.py — tell Django to use it
AUTH_USER_MODEL = "myapp.User"
AbstractUser mantiene todos los campos predeterminados de Django y la maquinaria de autenticación — solo agregas campos. El enfoque más simple y común.
from django.contrib.auth.models import AbstractBaseUser, BaseUserManager, PermissionsMixin
class User(AbstractBaseUser, PermissionsMixin):
email = models.EmailField(unique=True)
USERNAME_FIELD = "email" # log in with EMAIL instead of username
REQUIRED_FIELDS = []
objects = CustomUserManager() # a manager defining create_user/create_superuser
AbstractBaseUser te da control total sobre el modelo de usuario (por ejemplo, eliminar el nombre de usuario completamente para un inicio de sesión solo por email) — más trabajo, pero máxima flexibilidad.
from django.conf import settings
from django.contrib.auth import get_user_model
# in models — reference via settings.AUTH_USER_MODEL
author = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)
# in code — get the active user model dynamically
User = get_user_model() # NOT a direct import of the default User
Siempre haz referencia al modelo de usuario a través de settings.AUTH_USER_MODEL (en modelos) y get_user_model() (en código), nunca importando directamente el User predeterminado — así tu código funciona con el modelo personalizado.
Usar un modelo de usuario personalizado es conocimiento importante con una lección práctica crítica y frecuentemente enfatizada que todo desarrollador de Django debe interiorizar: configúralo al principio de cada proyecto.
La razón por la que esto importa tanto es la asimetría severa en dificultad — definir un modelo de usuario personalizado en el primer día (incluso una subclase AbstractUser vacía) no cuesta casi nada y proporciona una flexibilidad invaluable, mientras que cambiar a un modelo de usuario personalizado después de que el proyecto tiene migraciones y datos es extremadamente difícil y riesgoso, porque el modelo User está profundamente referenciado en toda Django (autenticación, admin, sesiones) y por claves foráneas en toda tu base de datos, requiriendo migraciones de datos complejas y propensas a errores para cambiar.
Esta es la razón por la que la propia documentación de Django recomienda fuertemente un modelo de usuario personalizado para cada nuevo proyecto, independientemente de la necesidad inmediata — es un seguro contra una pesadilla futura de migración.
Más allá de este consejo crítico de tiempo, entender cómo crear modelos de usuario personalizados — AbstractUser para simplemente agregar campos mientras mantienes el comportamiento de autenticación de Django (el caso común y fácil), y AbstractBaseUser para control total como inicio de sesión basado en email (eliminando completamente el nombre de usuario) — es valioso para cumplir con requisitos reales de aplicaciones (campos de usuario extra, identificadores de inicio de sesión alternativos, autenticación personalizada).
Igualmente importante es saber hacer referencia al modelo de usuario correctamente (a través de settings.AUTH_USER_MODEL y get_user_model(), nunca una importación directa) para que el código funcione con cualquier modelo de usuario que esté configurado.
Porque casi toda aplicación real tiene necesidades específicas del usuario más allá de los valores predeterminados de Django (y incluso aquellas que no tienen se benefician de la flexibilidad), y porque el costo de no configurar esto temprano es tan alto, entender modelos de usuario personalizados — especialmente el imperativo de establecer uno al inicio del proyecto — es conocimiento importante, prácticamente crítico, que previene un error común y grave a nivel de proyecto, convirtiéndolo en un conocimiento frecuentemente citado de las mejores prácticas de Django.