Personalizando a autenticação no Django¶

Especificando backends de autenticação¶

Por de trás dos panos, Django mantém uma lista de “backends de autenticação” que ele verifica para autenticação. Quando alguém chama: func:django.contrib.auth.authenticate() – como descrito em Como logar um usuário – Django tenta autenticar através de todas os backends de autenticações. Se o primeiro método falhar, Django tenta o segundo, e assim por diante, até todos os backends terem sido tentados.

A lista de backends autenticação usada é especificada na definição AUTHENTICATION_BACKENDS. Isto deve ser uma lista de nomes de caminhos Python que apontam para classes Python que sabem como autenticar. Essas classes podem estar em qualquer lugar no seu caminho Python (python path).

Por padrão, :settings:`AUTHENTICATION_BACKENDS` é definido como:

['django.contrib.auth.backends.ModelBackend']

Esta é o “backend” de autenticação básico que verifica o banco de dados de usuários Django e consulta as suas permissões embutidas. Ele não provê proteção contra ataques de força bruta via qualquer mecanismo limitante. Você pode implementar seu próprio mecanismo com taxa de limitação em um “backend” customizado de autenticação, ou usar o mecanismo fornecido pela maioria dos servidores Web.

A ordem dos :settings:`AUTHENTICATION_BACKENDS` importa, então se o mesmo usuário e senha são válidos em múltiplos backends, Django vai parar de processar na primeira combinação positiva.

Se um “backends” emitir uma exceção PermissionDenied, a autenticação irá falhar imediatamente. Django não irá verificar os próximos “backends”.

Desenvolvendo um backend de autenticação¶

Um backend de autenticação é uma classe que implementa dois métodos obirgatórios: get_user(user_id) e o authenticate(request, **credentials), assim como um conjunto opcional de métodos de autorização relacionados a permissão.

The get_user method takes a user_id – which could be a username, database ID or whatever, but has to be the primary key of your user object – and returns a user object or None.

O método authenticate recebe um argumento request e credenciais como argumentos nomeados. Na maioria das vezes, se parecerá com isso aqui:

class MyBackend:
    def authenticate(self, request, username=None, password=None):
        # Check the username/password and return a user.
        ...

Mas ele poderia também autenticar um token, tal qual:

class MyBackend:
    def authenticate(self, request, token=None):
        # Check the token and return a user.
        ...

Da mesma maneira, o authenticate() deve verificar as credenciais que recebeu e retornar um objeto do tipo “user” que combine com aquelas credenciais se estas forem válidas. Se as credenciais não forem válidas, ele deve retornar None.

O request é uma HttpRequest e pode ser None se não foi fornecido para o authenticate() (o qual o passa para o backend).

O Django admin está bem casado com o objeto User do Django. A melhor maneira de lidar com isso é criar um objeto User do Django para cada usuário que existir para seu “backend” (por ex.:, no seu diretório LDAP, seu banco de dados SQL externo e etc) Você pode inclusive escrever um script para fazer isso de ante-mão, ou seu método de autenticação pode fazê-lo na primeira vez que o usuário se logar.

Aqui um exemplo de “backend” que autentica com um nome de usuário e senha variáveis definidas no seu arquivo settings.py e cria um User Django na primeira vez que um usuário se autentique:

from django.conf import settings
from django.contrib.auth.hashers import check_password
from django.contrib.auth.models import User

class SettingsBackend:
    """
    Authenticate against the settings ADMIN_LOGIN and ADMIN_PASSWORD.

    Use the login name and a hash of the password. For example:

    ADMIN_LOGIN = 'admin'
    ADMIN_PASSWORD = 'pbkdf2_sha256$30000$Vo0VlMnkR4Bk$qEvtdyZRWTcOsCnI/oQ7fVOu1XAURIZYoOZ3iq8Dr4M='
    """

    def authenticate(self, request, username=None, password=None):
        login_valid = (settings.ADMIN_LOGIN == username)
        pwd_valid = check_password(password, settings.ADMIN_PASSWORD)
        if login_valid and pwd_valid:
            try:
                user = User.objects.get(username=username)
            except User.DoesNotExist:
                # Create a new user. There's no need to set a password
                # because only the password from settings.py is checked.
                user = User(username=username)
                user.is_staff = True
                user.is_superuser = True
                user.save()
            return user
        return None

    def get_user(self, user_id):
        try:
            return User.objects.get(pk=user_id)
        except User.DoesNotExist:
            return None

Lidando com autorização em bakends personalizados¶

Backends de autenticação customizados podem fornecer suas próprias permissões

O modelo de usuário irá delegar funções “lookup” de permissões (get_group_permissions(), get_all_permissions(), has_perm(), and has_module_perms()) para qualquer “backend” de autenticação que implemente essas funções.

As permissões dadas para o usuário será um super-conjunto de todas as permissões devolvidas de todos os back-ends . Ou seja , o Django concede uma permissão para um usuário que qualquer backend concederia.

Se um “backend” emiti uma exceção PermissionDenied no has_perm() ou has_module_perms(), a autorizaçõ irá falhar imediatamente e o Django não irá verificar os próximos “backends”.

O “backend” simples acima poderia implementar permissões para o mágico admin de maneira relativamente simples.

class SettingsBackend:
    ...
    def has_perm(self, user_obj, perm, obj=None):
        return user_obj.username == settings.ADMIN_LOGIN

Isso dá permissão total para o usuário para qual o acesso foi concedido no exemplo acima. Note que além dos mesmos argumentos dados as funções associadas ao usuário, todas as funções do “backend” de autenticação recebem o objeto user, o qual talvez seja um usuário anônimo, como argumento.

Uma implementação completa de autorização pode ser encontrada na classe ModelBackend no django/contrib/auth/backends.py, o qual é o “backend” padrão e consulta a tabela auth_permission na maior parte do tempo. Se você quer fornecer um comportamento personalizado para somente parte da API do “backend”, você pode tirar vantagem da herança Python e criar uma subclasse de ModelBackend ao invés de de implmentar a API completa em um “backend” customizado.

Usando um modelo de usuário personalizado quando iniciando um projeto¶

Se você estiver iniciando um novo projeto, é altamente recomendado que você defina um modelo de “user” personalizado, mesmo que o modelo padrão User seja suficiente pra você. Este modelo se comportará de maneira idêntica ao modelo “user” padrão, mas você será capaz de personalizá-lo no futuro caso a necessidade apareça.

from django.contrib.auth.models import AbstractUser

class User(AbstractUser):
    pass

Não se esqueça de indicá-lo no AUTH_USER_MODEL. Faça isso antes de criar qualquer migração ou antes de rodar um manage.py migrate pela primeira vez.

Além disso, registre o model no app’s ‘’admin.py’‘:

from django.contrib import admin
from django.contrib.auth.admin import UserAdmin
from .models import User

admin.site.register(User, UserAdmin)

Mudando para um modelo “user” personalizado no meio do projeto¶

Alterar o AUTH_USER_MODEL depois que tenha criado as tabelas no banco de dados é significantemente mais difícil já que isso afeta chaves estrangeiras e relacionamentos muitos-para-muitos, por exemplo.

Está modificação não pode ser feita automaticamente e requer um conserto manual do esquema, movendo os dados da antiga tabela de usuários e, possivelmente reaplicando manualmente algumas migrações. Veja #25313 para um esboço das etapas.

Devido às limitações do recurso de dependência dinâmica do Django para modelos intercambiáveis, o modelo referenciado por AUTH_USER_MODEL deve ser criado na primeira migração do seu aplicativo (usualmente chamada de 0001_initial); caso contrário, você terá problemas de dependência.

Além disso, você pode ter um `` CircularDependencyError`` ao executar suas migrações, pois o Django não será capaz de quebrar automaticamente o loop de dependência devido à dependência dinâmica. Se você tiver este erro, você deverá quebrar o loop movendo os modelos dependentes, do seu modelo de usuário, para uma segunda migração. (Você pode tentar criando dois modelos normais, onde cada um possui uma ForeignKey para o outro e ver como o makemigrations resolve essa dependência circular.)

Apps reusáveis e AUTH_USER_MODEL¶

Aplicações reutilizáveis não devem implmentar um modelo de usuário personalizado. Um projeto pode usar muitas aplicações, e duas aplicações reutilizáveis que implementam um modelo de usuário personalizado não poderiam ser usadas juntas. Se você precisa armazenar informação por usuário na sua aplicação, use um ForeignKey ou OneToOneField para o settings.AUTH_USER_MODEL como descrito abaixo.

Referenciando o modelo Usuário¶

Se você referênciar diretamente User (por exemplo, referenciando ele em uma chave estrangeira), seu código não ira funcionar em projetos onde a configuração AUTH_USER_MODEL tenha sido modificada para um modelo de usuário diferente.

get_user_model()[código fonte]¶

Ao invés de fazer uma referencia direta ao User, você deve referenciar o modelo do usuário usando o django.contrib.auth.get_user_model(). Este método irá retornar o modelo de usuário ativo no momento – o modelo de usuário personalizado se este estiver especificado, ou se não, o User.

Quando se define uma chave estrangeira ou relacionamentos muitos-para-muitos com o modelo de usuário, você deve especificar o modelo personalizado usando a definição AUTH_USER_MODEL. Por exemplo:

from django.conf import settings
from django.db import models

class Article(models.Model):
    author = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        on_delete=models.CASCADE,
    )

Quando conectar a sinais enviados pelo modelo de usuário, você deve especificar o modelo personalizado definindo o AUTH_USER_MODEL. Por exemplo:

from django.conf import settings
from django.db.models.signals import post_save

def post_save_receiver(sender, instance, created, **kwargs):
    pass

post_save.connect(post_save_receiver, sender=settings.AUTH_USER_MODEL)

De um modo geral, é mais fácil se referir ao modelo do usuário com o AUTH_USER_MODEL definindo no código que é executado no momento da importação, no entanto também é possível chamar get_user_model() enquanto o Django esta importando modelos, para que você possa usar models.ForeignKey(get_user_model(), ...).

If your app is tested with multiple user models, using @override_settings(AUTH_USER_MODEL=...) for example, and you cache the result of get_user_model() in a module-level variable, you may need to listen to the setting_changed signal to clear the cache. For example:

from django.apps import apps
from django.contrib.auth import get_user_model
from django.core.signals import setting_changed
from django.dispatch import receiver

@receiver(setting_changed)
def user_model_swapped(**kwargs):
    if kwargs['setting'] == 'AUTH_USER_MODEL':
        apps.clear_cache()
        from myapp import some_module
        some_module.UserModel = get_user_model()

Definindo um modelo de usuário personalizado.¶

O Django espera que seu modelo de usuário personalisado siga alguns preceitos básicos.

Se você usa o “backend” padrão de autenticação, então seu modelo deve ter um único campo “unique” que possa ser usado com o propósito de identificação. Isso pode ser um nome de usuário, um endereço de e-mail, ou qualquer atributo “unique”. Um nome de usuário que permita duplicaidade é permitido se você usar um “backend” de autenticação que dê suporte a isso.

A maneira mais fácil de construir um modelo de usuário personalizado compatível é herdar de AbstractBaseUser. A AbstractBaseUser fornece o mínimo necessário para implementar um modelo de usuário, incluindo senhas criptografadas e “resets” de senha. Você deve então fornecer alguns detalhes chaves da implementação:

class models.CustomUser¶

USERNAME_FIELD¶

Uma “string” descrevendo o nome do campo do modelo do usuário que é usado como identificador único. Geralmente será um nome de usuário de algum tipo, mas pode ser também o endereço de email, ou qualquer outro identificador único. O campo tem que ser “unique” (isto é, ter um unique=True na sua definição), a menos que seja utilizado um mecanismo de autenticação personalizado que permita nomes de usuários que não sejam únicos.

No exemplo seguinte, o campo identifier é usado como o campo identificador:

class MyUser(AbstractBaseUser):
    identifier = models.CharField(max_length=40, unique=True)
    ...
    USERNAME_FIELD = 'identifier'

EMAIL_FIELD¶

A string describing the name of the email field on the User model. This value is returned by get_email_field_name().

REQUIRED_FIELDS¶

Um lista de nomes de campos que serão demandados quando criar um usuário através do coando de gerenciamento createsuperuser. O usuário será demandado a fornecer um valor para cada um destes campos. Isso deve incluir qualquer campo para o qual o blank é False ou indefinido e pode incluir campos adicionais que você queira demandar quando o usuário for criado interativamente. O REQUIRED_FIELDS não tem efeito em outras partes do Django, como criar um usuario no admin.

Por exemplo, aqui é a definição parcial para um modelo de usuário que define dois campos obrigatórios - data de nascimento e peso:

class MyUser(AbstractBaseUser):
    ...
    date_of_birth = models.DateField()
    height = models.FloatField()
    ...
    REQUIRED_FIELDS = ['date_of_birth', 'height']

Nota

O REQUIRED_FIELDS deve conter todos os campos obrigatórios do seu modelo de usuário, mas não deve conter o USERNAME_FIELD ou password já que estes campos serão sempre requeridos.

is_active¶

Um atributo booleano que indica se o usuário é considerado “active”. Este atributo é fornecido como um atributo na AbstractBaseUser padronizado omo True. Como você escolhe como implementar isso irá depender dos detalhes do seu “backend” de autenticação escolhido. Veja a documentação do o atributo "is_active" do modelo de usuário embutido para detalhes.

get_full_name()¶

Optional. A longer formal identifier for the user such as their full name. If implemented, this appears alongside the username in an object’s history in django.contrib.admin.

get_short_name()¶

Optional. A short, informal identifier for the user such as their first name. If implemented, this replaces the username in the greeting to the user in the header of django.contrib.admin.

Changed in Django 2.0:

In older versions, subclasses are required to implement get_short_name() and get_full_name() as AbstractBaseUser has implementations that raise NotImplementedError.

Importando “AbstractBaseUser”

AbstractBaseUser and BaseUserManager are importable from django.contrib.auth.base_user so that they can be imported without including django.contrib.auth in INSTALLED_APPS.

Os atributos e métodos a seguir estão disponíveis em qualquer subclasse de AbstractBaseUser:

class models.AbstractBaseUser¶

get_username()¶

Retorna o valor do campo denominado no USERNAME_FIELD.

clean()¶

Normaliza o nome de usuário chamando normalize_username(). Se sobreescrever este método, lembre-se de chamar o super() para manter a normlização.

classmethod get_email_field_name()¶

Returns the name of the email field specified by the EMAIL_FIELD attribute. Defaults to 'email' if EMAIL_FIELD isn’t specified.

classmethod normalize_username(username)¶

Aplica normalização NFKC de UNICODE para nomes de usuários de modo que caracteres visualmente idênticos com pontos diferentes são considerados idênticos.

is_authenticated¶

Atributo somente de leitura que está sempre definido como True``(oposto ao `AnonymousUser.is_authenticated que é sempre False). Esta á a maneira de dizer se o usuário foi atenticado. Isso não implica em verificação de nenhuma permissão e não verifica se o usuário é ativo ou tem uma sessão válida. Mesmo que normalmente você irá verificar este atributo no request.user para descobrir se foi populado pelo AuthenticationMiddleware (representando o usuário logado atualmente), você deve saber se este atributo é True para qualquer instância de User.

is_anonymous¶

Atributo somente de leitura o qual é sempre definido como False. Esta é a maneira de diferenciar objetos do tipo User e AnonymousUser. Geralmente, você deve preferir usar o is_authenticated a este atributo.

set_password(raw_password)¶

Define a senha do usuário para uma dada string simples, levando em conta a criptografia da senha. Não salva o objeto AbstractBaseUser.

Quando a senha simples (plana) é None, a senha será definida como uma senha inutilizável, como se set_unusable_password() fosse usado.

check_password(raw_password)¶

Retorna ``True``se a string simples é a senha correta para o usuário. (leva em conta a criptografia da senha quando fizer a comparação.)

set_unusable_password()¶

Marca o usuário como não tendo uma senha definida. Não é o mesmo que uma string em branco para senha. check_password() para este usuário nunca retornará True. Não salva o objeto AbstractBaseUser.

Você talvez precise disso se a autenticação para sua aplicação é feita em uma fonte externa existente como um diretório LDAP.

has_usable_password()¶

Retorna False se set_unusable_password() foi chamado para este usuário.

get_session_auth_hash()¶

Retorna um HMAC do campo senha. Usado para “Invalidação de Sessão após a Troca de Senha.” isto é, invalidar sessão no caso de alteração de password.

AbstractUser subclasses AbstractBaseUser:

class models.AbstractUser¶

clean()¶

Normalizes the email by calling BaseUserManager.normalize_email(). If you override this method, be sure to call super() to retain the normalization.

Writing a manager for a custom user model¶

É necessário definir um “manager” personalizado para seu modelo de usuário. Se o seu modelo de usuário possui os campos username, email, is_staff, is_active, is_superuser, last_login, e date_joined como o modelo “User” padrão do Django’s, você pode simplesmente usar o UserManager do Django; porém, se o seu modelo de usuário define campos diferentes, você precisa definir um “manager” personzalido que herde de BaseUserManager fornecendo dois métodos adicionais:

class models.CustomUserManager¶

create_user(*username_field*, password=None, **other_fields)¶

O protótipo de create_user()``deve aceitar o campo "username" , mais todos os campos requeridos como argumentos. Por exemlo, se seu modelo de usuário usa ``email como o campo username, e tem date_of_birth como campo requerido, então create_user deve ser definido como:

def create_user(self, email, date_of_birth, password=None):
    # create user here
    ...

create_superuser(*username_field*, password, **other_fields)¶

O protótipo de create_superuser()``deve aceitar o campo "username" , mais todos os campos requeridos como argumentos. Por exemlo, se seu modelo de usuário usa ``email como o campo “username”, e tem date_of_birth como campo requerido, então create_user deve ser definido como:

def create_superuser(self, email, date_of_birth, password):
    # create superuser here
    ...

Diferente de create_user(), o create_superuser() deve requerer o “caller” para fornecer um password.

For a ForeignKey in USERNAME_FIELD or REQUIRED_FIELDS, these methods receive the value of the to_field (the primary_key by default) of an existing instance.

BaseUserManager fornece os seguintes métodos de utilidade:

class models.BaseUserManager¶

classmethod normalize_email(email)¶

Normaliza o endereço de email colocando em minúsculas a porção do domínio do endereço de email.

get_by_natural_key(username)¶

Retornar uma instância de usuário usando o conteúdo do campo denominado no USERNAME_FIELD.

make_random_password(length=10, allowed_chars='abcdefghjkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789')¶

Retorna uma senha randômica com o tamanho dado e a dada string de caracteres permitidos. Note que o calor padrão de allowed_chars não contém letrar que podem causar confusão, incluindo:

• i, l, I, e 1 (letra i minúscula, letra L maiúscula, letra i maiúscula, e o número um)
• o, O, e 0 (letra o minúscula, letra o maiúscula, e zero)

Estendendo o Usuário padrão do Django¶

If you’re entirely happy with Django’s User model and you just want to add some additional profile information, you could simply subclass django.contrib.auth.models.AbstractUser and add your custom profile fields, although we’d recommend a separate model as described in the “Model design considerations” note of Definindo um modelo de usuário personalizado.. AbstractUser provides the full implementation of the default User as an abstract model.

Usuários personalizados e o formulários de autenticação embutidos.¶

Os forms e views embutidos no Django tem certas premissas sobre o modelo de usuário que eles estão trabalhando.

Os “forms” seguintes são compatíveis com qualquer subclasse de AbstractBaseUser:

• A AuthenticationForm: usa o campo username especificado pelo USERNAME_FIELD.
• SetPasswordForm
• PasswordChangeForm
• AdminPasswordChangeForm

Os seguintes forms tem premissas sobre o modelo de usuário e podem ser usadas como estão se estas premissas forem atendidas:

• PasswordResetForm: Assumes that the user model has a field that stores the user’s email address with the name returned by get_email_field_name() (email by default) that can be used to identify the user and a boolean field named is_active to prevent password resets for inactive users.

Finalmente, os seguintes forms estão amarrados a User e precisa ser rescrito ou estendido para funcionar com o modelo de usuário personalizado:

• UserCreationForm
• UserChangeForm

Se o seu modelo de usuário personalizado é uma simples subclasse de AbstractUser, então você pode estender estes forms desta manera:

from django.contrib.auth.forms import UserCreationForm
from myapp.models import CustomUser

class CustomUserCreationForm(UserCreationForm):

    class Meta(UserCreationForm.Meta):
        model = CustomUser
        fields = UserCreationForm.Meta.fields + ('custom_field',)

Usuários personalizados e django.contrib.admin¶

Se você quer que seu modelo de usuário personalizado também funcione com o “admin”, seu modelo de usuário deve definir alguns atributos e métodos adicionais. Estes métodos permitem que o “admin” controle o acesso do usuário ao conteúdo do “admin”.

class models.CustomUser

is_staff¶

Retorna ``True``se o usuário está permitido a ter acesso ao site admin.

is_active¶

Retorna True se a conta de usuário estiver ativa.

has_perm(perm, obj=None):

Retorna True``se o usuário tem a permissão nominada. Se ``obj é fornecido, a permissão necessária para ser verificado para uma instância de objeto específica.

has_module_perms(app_label):

Retorna ``True``se o usuário tem permissão para acessar modelos na dada aplicação.

Você também irá precisar registrar seu modelo de usuário personalizado com o “admin”. Se seu modelo ersonalizado herda de django.contrib.auth.models.AbstractUser, você pode usar a classe já existente django.contrib.auth.admin.UserAdmin. Porém, se seu modelo de usuário herda de AbstractBaseUser, você precisa definir uma classe personalizada de ModelAdmin. Pode ser que seja possível herdar da django.contrib.auth.admin.UserAdmin padrão; porém, será necessário sobrescrever qualquer das definições que se referem a campos do ``django.contrib.auth.models.AbstractUser``e que não estejam no sua classe de usuário personalizado.

Usuários personalizados e permissões¶

Para tornar fácil a inclusão do mecanismo de permissão do Django na sua classe de usuário, o Django fornece a PermissionsMixin. Ela é uma classe de modelo abstrato que você pode incluir na hierarquia de classes do seu modelo, lhe dando todos os métodos e campos do banco de dados necessários de modo a funcionar como modelo de permissão do Django.

PermissionsMixin fornece os seguintes métodos e atributos:

class models.PermissionsMixin¶

is_superuser¶

Booleano. Designa que este user tem todas as permissões sem assinalá-las explicitamente.

get_group_permissions(obj=None)¶

Retorna um conjunto de strings de permissões que o usuário tem através de seus grupos.

Se o obj é passado, somente retorna o grupo de permissões para este objeto específico.

get_all_permissions(obj=None)¶

Retorna um conjunto de strings de permissões que o usuário tem, através de ambos permissões de grupo e usuário.

Se o obj é passado, somente retorna as permissões para este objeto específico.

has_perm(perm, obj=None)¶

Returns True if the user has the specified permission, where perm is in the format "<app label>.<permission codename>" (see permissions). If User.is_active and is_superuser are both True, this method always returns True.

Se obj é passado, este método não irá verificar por permissões para o modelo, mas para este objeto específico.

has_perms(perm_list, obj=None)¶

Returns True if the user has each of the specified permissions, where each perm is in the format "<app label>.<permission codename>". If User.is_active and is_superuser are both True, this method always returns True.

Se obj é passado, este método não irá verificar por permissões para o modelo, mas para este objeto específico.

has_module_perms(package_name)¶

Returns True if the user has any permissions in the given package (the Django app label). If User.is_active and is_superuser are both True, this method always returns True.

Usuários personalizados e modelos de proxy¶

Uma das limitações de modelos de usuário personalizados é que ao instalar uma classe de modelo de usuário personalizado qualquer modelo “proxy” que estenda a User irá quebrar. Modelos do tipo “proxy” devem ser baseados em uma classe base concreta; ao definir um modelo de usuário personalizado, você está removendo a habilidade do Django de identificar a classe base de maneira confiável.

Se seu projeto usa modelos “proxy”, você deve modificar o “proxy” para herdar do modelo de usuário em uso no seu projeto, ou juntar o comportamento do seu “proxy” dentro da sua subclasse de User.

Um exemplo completo¶

Here is an example of an admin-compliant custom user app. This user model uses an email address as the username, and has a required date of birth; it provides no permission checking, beyond a simple admin flag on the user account. This model would be compatible with all the built-in auth forms and views, except for the user creation forms. This example illustrates how most of the components work together, but is not intended to be copied directly into projects for production use.

Todo este código deve estar no arquivo “models.py” para um aplicativo de autenticação customizável:

from django.db import models
from django.contrib.auth.models import (
    BaseUserManager, AbstractBaseUser
)


class MyUserManager(BaseUserManager):
    def create_user(self, email, date_of_birth, password=None):
        """
        Creates and saves a User with the given email, date of
        birth and password.
        """
        if not email:
            raise ValueError('Users must have an email address')

        user = self.model(
            email=self.normalize_email(email),
            date_of_birth=date_of_birth,
        )

        user.set_password(password)
        user.save(using=self._db)
        return user

    def create_superuser(self, email, date_of_birth, password):
        """
        Creates and saves a superuser with the given email, date of
        birth and password.
        """
        user = self.create_user(
            email,
            password=password,
            date_of_birth=date_of_birth,
        )
        user.is_admin = True
        user.save(using=self._db)
        return user


class MyUser(AbstractBaseUser):
    email = models.EmailField(
        verbose_name='email address',
        max_length=255,
        unique=True,
    )
    date_of_birth = models.DateField()
    is_active = models.BooleanField(default=True)
    is_admin = models.BooleanField(default=False)

    objects = MyUserManager()

    USERNAME_FIELD = 'email'
    REQUIRED_FIELDS = ['date_of_birth']

    def __str__(self):
        return self.email

    def has_perm(self, perm, obj=None):
        "Does the user have a specific permission?"
        # Simplest possible answer: Yes, always
        return True

    def has_module_perms(self, app_label):
        "Does the user have permissions to view the app `app_label`?"
        # Simplest possible answer: Yes, always
        return True

    @property
    def is_staff(self):
        "Is the user a member of staff?"
        # Simplest possible answer: All admins are staff
        return self.is_admin

Then, to register this custom user model with Django’s admin, the following code would be required in the app’s admin.py file:

from django import forms
from django.contrib import admin
from django.contrib.auth.models import Group
from django.contrib.auth.admin import UserAdmin as BaseUserAdmin
from django.contrib.auth.forms import ReadOnlyPasswordHashField

from customauth.models import MyUser


class UserCreationForm(forms.ModelForm):
    """A form for creating new users. Includes all the required
    fields, plus a repeated password."""
    password1 = forms.CharField(label='Password', widget=forms.PasswordInput)
    password2 = forms.CharField(label='Password confirmation', widget=forms.PasswordInput)

    class Meta:
        model = MyUser
        fields = ('email', 'date_of_birth')

    def clean_password2(self):
        # Check that the two password entries match
        password1 = self.cleaned_data.get("password1")
        password2 = self.cleaned_data.get("password2")
        if password1 and password2 and password1 != password2:
            raise forms.ValidationError("Passwords don't match")
        return password2

    def save(self, commit=True):
        # Save the provided password in hashed format
        user = super().save(commit=False)
        user.set_password(self.cleaned_data["password1"])
        if commit:
            user.save()
        return user


class UserChangeForm(forms.ModelForm):
    """A form for updating users. Includes all the fields on
    the user, but replaces the password field with admin's
    password hash display field.
    """
    password = ReadOnlyPasswordHashField()

    class Meta:
        model = MyUser
        fields = ('email', 'password', 'date_of_birth', 'is_active', 'is_admin')

    def clean_password(self):
        # Regardless of what the user provides, return the initial value.
        # This is done here, rather than on the field, because the
        # field does not have access to the initial value
        return self.initial["password"]


class UserAdmin(BaseUserAdmin):
    # The forms to add and change user instances
    form = UserChangeForm
    add_form = UserCreationForm

    # The fields to be used in displaying the User model.
    # These override the definitions on the base UserAdmin
    # that reference specific fields on auth.User.
    list_display = ('email', 'date_of_birth', 'is_admin')
    list_filter = ('is_admin',)
    fieldsets = (
        (None, {'fields': ('email', 'password')}),
        ('Personal info', {'fields': ('date_of_birth',)}),
        ('Permissions', {'fields': ('is_admin',)}),
    )
    # add_fieldsets is not a standard ModelAdmin attribute. UserAdmin
    # overrides get_fieldsets to use this attribute when creating a user.
    add_fieldsets = (
        (None, {
            'classes': ('wide',),
            'fields': ('email', 'date_of_birth', 'password1', 'password2')}
        ),
    )
    search_fields = ('email',)
    ordering = ('email',)
    filter_horizontal = ()

# Now register the new UserAdmin...
admin.site.register(MyUser, UserAdmin)
# ... and, since we're not using Django's built-in permissions,
# unregister the Group model from admin.
admin.site.unregister(Group)

Finalmente, especifique o model customizado como sendo o “user model” padrão para o seu projeto, utilizando para isso, AUTH_USER_MODEL no arquivo “settings.py”:

AUTH_USER_MODEL = 'customauth.MyUser'