---
title: "Personalizando a autenticação no Django"
version: 6.1
locale: pt-br
source: https://docs.djangoproject.com/pt-br/6.1/topics/auth/customizing/
canonical: https://djangodocs.dev/pt-br/6.1/topics/auth/customizing/
---
# Personalizando a autenticação no Django

A autenticação que vem com o Django é boa o suficiente para os casos mais comuns, mas você pode ter necessidades não atendidas pelo padrão out-of-the-box. Personalizar a autenticação em seus projetos requer entender que pontos do sistema fornecido são extensíveis ou substituíveis. Este documento fornece detalhes sobre como o sistema de autenticação pode ser personalizado.

[Authentication backends](#authentication-backends)  fornece um sistema extensível para quando um nome de usuário e uma senha, armazenados com o modelo de usuário, precisam ser autenticados contra um serviço diferente do padrão do Django.

Você pode dar para seus models  [permissões customizadas](#custom-permissions) que pode ser conferidas através do sistema de autorização do Django.

Você pode [extender](#extending-user) o modelo `User` padrão, ou [substituir](#auth-custom-user) por um modelo completamente personalizado.

## Outras fontes de autenticação

Pode haver várias vezes que você precise enganchar em outro código de autenticação, outro código de usuário ou senha ou métodos de autenticação.

Por exemplo, sua companhia pode já ter um LDAP configurado que armazena o usuário e a senha para cada empregado. Isto é um aborrecimento para ambos administradores de rede e os próprios usuários se os usuários tiverem contas separadas em LDAP e a aplicação baseada em Django.

Então, para lidar com situações como está, o sistema de autenticação do Django deixa você conectá-lo em outras fontes de autenticação. Você pode sobrescrever o esquema padrão baseado em banco de dados, ou você pode usar o sistema padrão em conjunto com outros sistemas.

Veja a [referência do backend de autenticação](/pt-br/6.1/ref/contrib/auth/#authentication-backends-reference) para informação sobre backends de autenticação incluída com Django.

### Especificando backends de autenticação

Behind the scenes, Django maintains a list of “authentication backends” that it
checks for authentication. When somebody calls
[`django.contrib.auth.authenticate()`](/pt-br/6.1/topics/auth/default/#django.contrib.auth.authenticate) – as described in [How to log
a user in](/pt-br/6.1/topics/auth/default/#how-to-log-a-user-in) – Django tries authenticating across
all of its authentication backends. If the first authentication method fails,
Django tries the second one, and so on, until all backends have been attempted.

A lista de backends autenticação usada é especificada na definição [`AUTHENTICATION_BACKENDS`](/pt-br/6.1/ref/settings/#std-setting-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,  é definido como:

```
["django.contrib.auth.backends.ModelBackend"]
```

That’s the basic authentication backend that checks the Django users database
and queries the built-in permissions. It does not provide protection against
brute force attacks via any rate limiting mechanism. You may either implement
your own rate limiting mechanism in a custom auth backend, or use the
mechanisms provided by most web servers.

A ordem dos  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`](/pt-br/6.1/ref/exceptions/#django.core.exceptions.PermissionDenied), a autenticação irá falhar imediatamente. Django não irá verificar os próximos “backends”.

> **Note**
>
> Once a user has authenticated, Django stores which backend was used to
> authenticate the user in the user’s session, and reuses the same backend
> for the duration of that session whenever access to the currently
> authenticated user is needed. This effectively means that authentication
> sources are cached on a per-session basis, so if you change
> [`AUTHENTICATION_BACKENDS`](/pt-br/6.1/ref/settings/#std-setting-AUTHENTICATION_BACKENDS), you’ll need to clear out session data
> if you need to force users to re-authenticate using different methods. A
> simple way to do that is to execute `Session.objects.all().delete()`.

### 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](#authorization-methods) relacionados a permissão.

O método `get_user` recebe um `user_id` – o qual pode ser um username, ID do banco de dados ou outr coisa qualquer, mas tem que ser uma chave-primária do seu objeto user – e retorna um objeto user ou `None`.

The `authenticate` method takes a `request` argument and credentials as
keyword arguments. Most of the time, it’ll look like this:

```
from django.contrib.auth.backends import BaseBackend

class MyBackend(BaseBackend):
    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:

```
from django.contrib.auth.backends import BaseBackend

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

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

O `request` é uma [`HttpRequest`](/pt-br/6.1/ref/request-response/#django.http.HttpRequest) e pode ser `None` se não foi fornecido para a [`authenticate()`](/pt-br/6.1/topics/auth/default/#django.contrib.auth.authenticate) (a qual o passa para o backend).

The Django admin is tightly coupled to the Django [User object](/pt-br/6.1/topics/auth/default/#user-objects). For example, for a user to access the admin,
[`User.is_staff`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User.is_staff) and [`User.is_active`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User.is_active) must be `True` (see
[`AdminSite.has_permission()`](/pt-br/6.1/ref/contrib/admin/#django.contrib.admin.AdminSite.has_permission) for details).

The best way to deal with this is to create a Django `User` object for each
user that exists for your backend (e.g., in your LDAP directory, your external
SQL database, etc.). You can either write a script to do this in advance, or
your `authenticate` method can do it the first time a user logs in.

Here’s an example backend that authenticates against a username and password
variable defined in your `settings.py` file and creates a Django `User`
object the first time a user authenticates. In this example, the created Django
`User` object is a superuser who will have full access to the admin:

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

class SettingsBackend(BaseBackend):
    """
    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)  # is_active defaults to True.
                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

The user model and its manager will delegate permission lookup functions
([`get_user_permissions()`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User.get_user_permissions),
[`get_group_permissions()`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User.get_group_permissions),
[`get_all_permissions()`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User.get_all_permissions),
[`has_perm()`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User.has_perm),
[`has_module_perms()`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User.has_module_perms), and
[`with_perm()`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.UserManager.with_perm)) to any
authentication backend that implements these functions.

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 conceder.

If a backend raises a [`PermissionDenied`](/pt-br/6.1/ref/exceptions/#django.core.exceptions.PermissionDenied)
exception in [`has_perm()`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User.has_perm) or
[`has_module_perms()`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User.has_module_perms), the authorization
will immediately fail and Django won’t check the backends that follow.

A backend could implement permissions for the magic admin like this:

```
from django.contrib.auth.backends import BaseBackend

class MagicAdminBackend(BaseBackend):
    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.

A full authorization implementation can be found in the `ModelBackend` class
in [django/contrib/auth/backends.py](https://github.com/django/django/blob/stable/6.1.x/django/contrib/auth/backends.py), which is the default backend and
queries the `auth_permission` table most of the time.

#### Autorização para usuários anônimos

Um usuário anônimo é um que não está autenticado poe exemplo ele forneceu detalhes de autenticação não válidos. Todavia, isso não quer dizer necessariamente que eles não estão autorizados a fazer nada. Em um nível mais básico, a maioria dos websites autorizam usuário anônimos a navegar a maior parte do site, e muitos permitem enviar comentários e etc.

Django’s permission framework does not have a place to store permissions for
anonymous users. However, the user object passed to an authentication backend
may be an [`django.contrib.auth.models.AnonymousUser`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.AnonymousUser) object, allowing
the backend to specify custom authorization behavior for anonymous users. This
is especially useful for the authors of reusable apps, who can delegate all
questions of authorization to the auth backend, rather than needing settings,
for example, to control anonymous access.

#### Autorização para usuários inativos

Um “user” inativo é o aquele que tem seu campo  [`is_active`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User.is_active) definido como `False`. Os backends de autenticação [`ModelBackend`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.backends.ModelBackend) e [`RemoteUserBackend`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.backends.RemoteUserBackend) não permitem que este usuário se autentique. Se um modelo personalizado de “user” não tem o [`is_active`](#django.contrib.auth.models.CustomUser.is_active), todos os usuários serão permitidos a se autenticar.

Você pode usar a [`AllowAllUsersModelBackend`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.backends.AllowAllUsersModelBackend) ou [`AllowAllUsersRemoteUserBackend`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.backends.AllowAllUsersRemoteUserBackend) se quiser que usuários inativos se autentiquem.

O suporte para usuários anônimos no sistema de permissão permite um cenário onde usuários anônimos tem permissões de fazer alguma coisa enquanto usuário autenticados inativos não.

Não se esqueça de testar o atributo `is_active` do usuário nos métodos de permissão do seu próprio backend.

#### Manipulação de permissões de objeto

O framework de permissões do Django tem uma “foundation” para objetos de permissões, embora não haja uma implementação para isso no core. Isso significa que a verificação para permissões de objetos sempre retorna `False` ou uma lista vazia (dependendo da verificação realizada). Um “backend” de autenticação receberá os parâmetros nomeados `obj` e `user_obj` para cada método de autorização relacionado com o objeto e pode retornar o nível de permissão do objeto como for apropriado.

## Permissões personalizadas

Para criar permissões persaonalizadas para um dado objeto de modelo, use o `permissions` [model Meta attribute](/pt-br/6.1/topics/db/models/#meta-options).

This example `Task` model creates two custom permissions, i.e., actions users
can or cannot do with `Task` instances, specific to your application:

```
class Task(models.Model):
    ...

    class Meta:
        permissions = [
            ("change_task_status", "Can change the status of tasks"),
            ("close_task", "Can remove a task by setting its status as closed"),
        ]
```

The only thing this does is create those extra permissions when you run
[`manage.py migrate`](/pt-br/6.1/ref/django-admin/#django-admin-migrate) (the function that creates permissions
is connected to the [`post_migrate`](/pt-br/6.1/ref/signals/#django.db.models.signals.post_migrate) signal).
Your code is in charge of checking the value of these permissions when a user
is trying to access the functionality provided by the application (changing the
status of tasks or closing tasks.) Continuing the above example, the following
checks if a user may close tasks:

```
user.has_perm("app.close_task")
```

## Estendendo o modelo `Usuário` existente

Existem duas maneiras de estender o modelo padrão [`User`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User) sem substituir seu próprio modelo. Se as mnudanças que precisa são puramente comprtamentais, e nao requerem nenhuma mudança no que é armazenado no banco de dados, você pode criar um [proxy model](/pt-br/6.1/topics/db/models/#proxy-models)  baseado na  [`User`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User). Isso permite qualquer das funcionalidades oferecidas pelo modelo “proxy” incluindo “ordering” padrão, “managers” personalizados ou métodos persononalizados do modelo.

Se você deseja armazenar informação relacionada ao `User`, você pode usar a [`OneToOneField`](/pt-br/6.1/ref/models/fields/#django.db.models.OneToOneField) para um modelo contento os campos para a informação adicional. Este modelo com relação um-pra-um é muitas vezes chamado modelo de perfil, uma vez que poderia armazenar infomração que nao está relacionada com autenticação sobre o usuário do site. Por exemplo você poderia criar um modelo “Employee”

```
from django.contrib.auth.models import User

class Employee(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE)
    department = models.CharField(max_length=100)
```

Assuming an existing Employee Fred Smith who has both a User and Employee
model, you can access the related information using Django’s standard related
model conventions:

```pycon
>>> u = User.objects.get(username="fsmith")
>>> freds_department = u.employee.department
```

Para adicionar os campos do modelo de perfil para uma página de usuário no admin, defina uma [`InlineModelAdmin`](/pt-br/6.1/ref/contrib/admin/#django.contrib.admin.InlineModelAdmin) (para este exemplo, iremos usar uma [`StackedInline`](/pt-br/6.1/ref/contrib/admin/#django.contrib.admin.StackedInline)) no `admin.py` da sua aplicação e a adicione a classe `UserAdmin` a qual é registrada com a classe [`User`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User):

```
from django.contrib import admin
from django.contrib.auth.admin import UserAdmin as BaseUserAdmin
from django.contrib.auth.models import User

from my_user_profile_app.models import Employee

# Define an inline admin descriptor for Employee model
# which acts a bit like a singleton
class EmployeeInline(admin.StackedInline):
    model = Employee
    can_delete = False
    verbose_name_plural = "employee"

# Define a new User admin
class UserAdmin(BaseUserAdmin):
    inlines = [EmployeeInline]

# Re-register UserAdmin
admin.site.unregister(User)
admin.site.register(User, UserAdmin)
```

Os modelos “profile” não são especiais de maneira alguma - eles são apenas modelos Django que possuem uma relação um-para-um com o modelo “user”. Assim sendo, eles não são criados automaticamente quando um usuário é criado, más um [`django.db.models.signals.post_save`](/pt-br/6.1/ref/signals/#django.db.models.signals.post_save) pode ser usado para criar ou atualizar um modelo relacionado se for apropriado.

Usar modelos relacionados resultam em “queries” adicionais ou “joins” para retornar os dados relacionados. Dependendo de suas necessidades, talvez seja uma melhor opção um modelo “user” customizado que inclua os campos relacionados, porém, relações com o modelo “user” já existente dentro das apps do seu projeto talvez justifiquem a carga extra do banco de dados.

## Substituindo um modelo de `Usuário` personalizado

Alguns tipos de projetos talvez tenham requerimentos de autenticação para as quais o modelo [`User`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User) embutido do Django nem sempre é apropriado. Por exemplo, em alguns sites tenha mais sentido usar um endereço de e-mail como seu “token” de identificação no lugar de um nome de usuáro.

O Django permite que você sobrescreva o modelo “user” padrão, fornecendo um valor para o [`AUTH_USER_MODEL`](/pt-br/6.1/ref/settings/#std-setting-AUTH_USER_MODEL) definindo a referência para um modelo personalizado:

```
AUTH_USER_MODEL = "myapp.MyUser"
```

This dotted pair describes the [`label`](/pt-br/6.1/ref/applications/#django.apps.AppConfig.label) of the
Django app (which must be in your [`INSTALLED_APPS`](/pt-br/6.1/ref/settings/#std-setting-INSTALLED_APPS)), and the name of
the Django model that you wish to use as your user model.

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

If you’re starting a new project, you can set up a custom user model that
behaves identically to the default user model by subclassing
[`AbstractUser`](#django.contrib.auth.models.AbstractUser):

```
from django.contrib.auth.models import AbstractUser

class User(AbstractUser):
    pass
```

Não se esqueça de indicá-lo no [`AUTH_USER_MODEL`](/pt-br/6.1/ref/settings/#std-setting-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

Changing [`AUTH_USER_MODEL`](/pt-br/6.1/ref/settings/#std-setting-AUTH_USER_MODEL) after you’ve created database tables is
possible, but can be complex, since it affects foreign keys and many-to-many
relationships, for example.

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](https://code.djangoproject.com/ticket/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`](/pt-br/6.1/ref/settings/#std-setting-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`](/pt-br/6.1/ref/models/fields/#django.db.models.ForeignKey) ou [`OneToOneField`](/pt-br/6.1/ref/models/fields/#django.db.models.OneToOneField) para o `settings.AUTH_USER_MODEL` como descrito abaixo.

### Referenciando o modelo `Usuário`

Se você referênciar diretamente [`User`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.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`](/pt-br/6.1/ref/settings/#std-setting-AUTH_USER_MODEL) tenha sido modificada para um modelo de usuário diferente.

#### `get_user_model()`

Ao invés de fazer uma referencia direta ao [`User`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.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`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.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`](/pt-br/6.1/ref/settings/#std-setting-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`](/pt-br/6.1/ref/settings/#std-setting-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`](/pt-br/6.1/ref/settings/#std-setting-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`](/pt-br/6.1/ref/signals/#django.test.signals.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(*, setting, **kwargs):
    if 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.

When you start your project with a custom user model, stop to consider if this
is the right choice for your project.

Keeping all user related information in one model removes the need for
additional or more complex database queries to retrieve related models. On the
other hand, it may be more suitable to store app-specific user information in a
model that has a relation with your custom user model. That allows each app to
specify its own user data requirements without potentially conflicting or
breaking assumptions by other apps. It also means that you would keep your user
model as simple as possible, focused on authentication, and following the
minimum requirements Django expects custom user models to meet.

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`](#django.contrib.auth.models.AbstractBaseUser). A [`AbstractBaseUser`](#django.contrib.auth.models.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`

A string describing the name of the field on the user model that is
used as the unique identifier. This will usually be a username of some
kind, but it can also be an email address, or any other unique
identifier. The field *must* be unique (e.g. have `unique=True` set
in its definition), unless you use a custom authentication backend that
can support non-unique usernames.

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()`](#django.contrib.auth.models.AbstractBaseUser.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`](/pt-br/6.1/ref/django-admin/#django-admin-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`](/pt-br/6.1/ref/models/fields/#django.db.models.Field.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"]
```

> **Note**
>
> 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`

A boolean attribute that indicates whether the user is considered
“active”. This attribute is provided as an attribute on
`AbstractBaseUser` defaulting to `True`. How you choose to
implement it will depend on the details of your chosen auth backends.
See the documentation of the [`is_active attribute on the built-in
user model`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User.is_active) for details.

#### `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`](/pt-br/6.1/ref/contrib/admin/#module-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`](/pt-br/6.1/ref/contrib/admin/#module-django.contrib.admin).

> **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`](/pt-br/6.1/ref/settings/#std-setting-INSTALLED_APPS).

Os atributos e métodos a seguir estão disponíveis em qualquer subclasse de [`AbstractBaseUser`](#django.contrib.auth.models.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()`](#django.contrib.auth.models.AbstractBaseUser.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`](#django.contrib.auth.models.CustomUser.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`](/pt-br/6.1/ref/middleware/#django.contrib.auth.middleware.AuthenticationMiddleware) (representando o usuário logado atualmente), você deve saber se este atributo é `True` para qualquer instância de [`User`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User).

#### `is_anonymous`

Atributo somente de leitura o qual é sempre definido como `False`. Esta é a maneira de diferenciar objetos do tipo [`User`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User) e [`AnonymousUser`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.AnonymousUser). Geralmente, você deve preferir usar o [`is_authenticated`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User.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`](#django.contrib.auth.models.AbstractBaseUser).

When the raw\_password is `None`, the password will be set to an
unusable password, as if
[`set_unusable_password()`](#django.contrib.auth.models.AbstractBaseUser.set_unusable_password)
were used.

#### `check_password(raw_password)`

#### `acheck_password(raw_password)`

*Asynchronous version*: `acheck_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()`

Marks the user as having no password set. This isn’t the same as
having a blank string for a password.
[`check_password()`](#django.contrib.auth.models.AbstractBaseUser.check_password) for
this user will never return `True`. Doesn’t save the
[`AbstractBaseUser`](#django.contrib.auth.models.AbstractBaseUser) object.

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()`

Returns `False` if
[`set_unusable_password()`](#django.contrib.auth.models.AbstractBaseUser.set_unusable_password)
has been called for this user.

#### `get_session_auth_hash()`

Retorna um HMAC do campo senha. Usado para “[Invalidação de Sessão após a Troca de Senha.](/pt-br/6.1/topics/auth/default/#session-invalidation-on-password-change)” isto é, invalidar sessão no caso de alteração de password.

#### `get_session_auth_fallback_hash()`

Yields the HMAC of the password field using
[`SECRET_KEY_FALLBACKS`](/pt-br/6.1/ref/settings/#std-setting-SECRET_KEY_FALLBACKS). Used by `get_user()`.

[`AbstractUser`](#django.contrib.auth.models.AbstractUser) subclasses [`AbstractBaseUser`](#django.contrib.auth.models.AbstractBaseUser):

#### `class models.AbstractUser`

#### `clean()`

Normalizes the email by calling
[`BaseUserManager.normalize_email()`](#django.contrib.auth.models.BaseUserManager.normalize_email). If you override this method,
be sure to call `super()` to retain the normalization.

### Escrevendo um manager para um modelo de usuário customizado

You should also define a custom manager for your user model. If your user model
defines `username`, `email`, `is_staff`, `is_active`, `is_superuser`,
`last_login`, and `date_joined` fields the same as Django’s default user,
you can install Django’s [`UserManager`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.UserManager);
however, if your user model defines different fields, you’ll need to define a
custom manager that extends
[`BaseUserManager`](#django.contrib.auth.models.BaseUserManager) providing two additional
methods:

#### `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=None, **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=None):
    # create superuser here
    ...
```

For a [`ForeignKey`](/pt-br/6.1/ref/models/fields/#django.db.models.ForeignKey) in [`USERNAME_FIELD`](#django.contrib.auth.models.CustomUser.USERNAME_FIELD) or
[`REQUIRED_FIELDS`](#django.contrib.auth.models.CustomUser.REQUIRED_FIELDS), these methods receive the value of the
[`to_field`](/pt-br/6.1/ref/models/fields/#django.db.models.ForeignKey.to_field) (the [`primary_key`](/pt-br/6.1/ref/models/fields/#django.db.models.Field.primary_key)
by default) of an existing instance.

[`BaseUserManager`](#django.contrib.auth.models.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)`

#### `aget_by_natural_key(username)`

*Asynchronous version*: `aget_by_natural_key()`

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

### Estendendo o `Usuário` padrão do Django

If you’re entirely happy with Django’s
[`User`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User) model, but you want to add some
additional profile information, you could subclass
[`django.contrib.auth.models.AbstractUser`](#django.contrib.auth.models.AbstractUser) and add your custom profile
fields, although we’d recommend a separate model as described in
[Definindo um modelo de usuário personalizado.](#specifying-custom-user-model). `AbstractUser` provides the full
implementation of the default [`User`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User) as an
[abstract model](/pt-br/6.1/topics/db/models/#abstract-base-classes).

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

Os [forms](/pt-br/6.1/topics/auth/default/#built-in-auth-forms) e [views](/pt-br/6.1/topics/auth/default/#built-in-auth-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`](#django.contrib.auth.models.AbstractBaseUser):

- A [`AuthenticationForm`](/pt-br/6.1/topics/auth/default/#django.contrib.auth.forms.AuthenticationForm): usa o campo username especificado pelo [`USERNAME_FIELD`](#django.contrib.auth.models.CustomUser.USERNAME_FIELD).
- [`SetPasswordForm`](/pt-br/6.1/topics/auth/default/#django.contrib.auth.forms.SetPasswordForm)
- [`PasswordChangeForm`](/pt-br/6.1/topics/auth/default/#django.contrib.auth.forms.PasswordChangeForm)
- [`AdminPasswordChangeForm`](/pt-br/6.1/topics/auth/default/#django.contrib.auth.forms.AdminPasswordChangeForm)

Os seguintes forms fazem suposições quanto ao modelo de usuário e podem ser usadas tal como estão se estas suposições forem válidas:

- [`PasswordResetForm`](/pt-br/6.1/topics/auth/default/#django.contrib.auth.forms.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()`](#django.contrib.auth.models.AbstractBaseUser.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`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User) e precisa ser rescrito ou estendido para funcionar com o modelo de usuário personalizado:

- [`UserCreationForm`](/pt-br/6.1/topics/auth/default/#django.contrib.auth.forms.UserCreationForm)
- [`UserChangeForm`](/pt-br/6.1/topics/auth/default/#django.contrib.auth.forms.UserChangeForm)

If your custom user model is a subclass of `AbstractUser`, then you can
extend these forms in this manner:

```
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`](/pt-br/6.1/ref/contrib/admin/#module-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`](#django.contrib.auth.models.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.

> **Note**
>
> If you are using a custom `ModelAdmin` which is a subclass of
> `django.contrib.auth.admin.UserAdmin`, then you need to add your custom
> fields to `fieldsets` (for fields to be used in editing users) and to
> `add_fieldsets` (for fields to be used when creating a user). For
> example:
>
> ```
> from django.contrib.auth.admin import UserAdmin
>
>
> class CustomUserAdmin(UserAdmin):
>     ...
>     fieldsets = UserAdmin.fieldsets + ((None, {"fields": ["custom_field"]}),)
>     add_fieldsets = UserAdmin.add_fieldsets + ((None, {"fields": ["custom_field"]}),)
> ```
>
> See [a full example](#custom-users-admin-full-example) for more
> details.

### 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`](#django.contrib.auth.models.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`](#django.contrib.auth.models.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_user_permissions(obj=None)`

Returns a set of permission strings that the user has directly.

If `obj` is passed in, only returns the user permissions for this
specific object.

#### `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](/pt-br/6.1/topics/auth/default/#topic-authorization)). If [`User.is_active`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User.is_active)
and [`is_superuser`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User.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`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User.is_active) and
[`is_superuser`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User.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`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User.is_active) and
[`is_superuser`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.User.is_superuser) are both `True`, this method always
returns `True`.

> **PermissionsMixin e ModelBackend**
>
> Caso não inclua a [`PermissionsMixin`](#django.contrib.auth.models.PermissionsMixin), você deve se assegurar que os métodos de permissões não sejam chamados no `ModelBackend`. O `ModelBackend` assume que determinados campos estão disponíveis no seu modelo. Se o seu modelo de usuário não provê estes campos, você irá receber erros de banco de dados quando as permissões forem verificadas.

### 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`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.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`](/pt-br/6.1/ref/contrib/auth/#django.contrib.auth.models.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 an `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=None):
        """
        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 django.core.exceptions import ValidationError

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 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
    disabled password hash display field.
    """

    password = ReadOnlyPasswordHashField()

    class Meta:
        model = MyUser
        fields = ["email", "password", "date_of_birth", "is_active", "is_admin"]

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`](/pt-br/6.1/ref/settings/#std-setting-AUTH_USER_MODEL)  no arquivo “settings.py”:

```
AUTH_USER_MODEL = "customauth.MyUser"
```

#### Adding an async interface

To optimize performance when called from an async context authentication,
backends can implement async versions of each function - `aget_user(user_id)`
and `aauthenticate(request, **credentials)`. When an authentication backend
extends `BaseBackend` and async versions of these functions are not provided,
they will be automatically synthesized with `sync_to_async`. This has
[performance penalties](/pt-br/6.1/topics/async/#async-performance).

While an async interface is optional, a synchronous interface is always
required. There is no automatic synthesis for a synchronous interface if an
async interface is implemented.

Django’s out-of-the-box authentication backends have native async support. If
these native backends are extended take special care to make sure the async
versions of modified functions are modified as well.