Então, vamos rever de um ponto de vista simplificado:

* O usuário digita o `username` e a `senha` no frontend e aperta `Enter`.
* O frontend (rodando no browser do usuário) manda o `username` e a `senha` para uma URL específica na sua API (declarada com `tokenUrl="token"`).
* A API checa aquele `username` e `senha`, e responde com um "token" (nós não implementamos nada disso ainda).

Caso ela não receba, ela retorna um erro HTTP 401 "Unauthorized" (*Não Autorizado*).

E retorna um cabeçalho `WWW-Authenticate` com o valor `Basic`, e um parâmetro opcional `realm`.

Isso sinaliza ao navegador para mostrar o prompt integrado para um usuário e senha.

Então, quando você digitar o usuário e senha, o navegador os envia automaticamente no cabeçalho.

## Hashing de senhas

"Hashing" significa converter algum conteúdo (uma senha neste caso) em uma sequência de bytes (apenas uma string) que parece um monte de caracteres sem sentido.

Sempre que você passar exatamente o mesmo conteúdo (exatamente a mesma senha), você obterá exatamente o mesmo resultado.

Mas não é possível converter os caracteres sem sentido de volta para a senha original.

### Por que usar hashing de senhas

errors.invalid_kuromoji_segmentation=O número de divisões de {0} não corresponde ao número de divisões de {1}.
errors.invalid_str_is_included = {1} é inválido em {0}.
errors.blank_password = A senha é obrigatória.
errors.invalid_confirm_password = A confirmação da senha não corresponde.
errors.cannot_delete_doc_because_of_running = O rastreador está em execução. Não é possível excluir o documento.

# Simples OAuth2 com senha e Bearer

Agora vamos construir a partir do capítulo anterior e adicionar as partes que faltam para ter um fluxo de segurança completo.

## Pegue o `username` (nome de usuário) e `password` (senha)

É utilizado o utils de segurança da **FastAPI** para obter o `username` e a `password`.

Agora, sempre que um navegador estiver criando um usuário com uma senha, a API retornará a mesma senha na resposta.

Neste caso, pode não ser um problema, porque é o mesmo usuário enviando a senha.

Mas se usarmos o mesmo modelo para outra *operação de rota*, poderíamos estar enviando as senhas dos nossos usuários para todos os clientes.

/// danger | Perigo

labels.suggestWord=Palavra sugerida
labels.targetLabel=Rótulo
labels.term=Termo de pesquisa
labels.fields=Campos
labels.ex_q=Consulta estendida
labels.oldPassword=Senha atual
labels.newPassword=Nova senha
labels.confirmNewPassword=Confirmar nova senha
labels.menu_system=Sistema
labels.menu_wizard=Assistente
labels.menu_crawl_config=Geral
labels.menu_scheduler_config=Agendador
labels.menu_dashboard_config=Painel

* O **modelo de entrada** precisa ser capaz de ter uma senha.
* O **modelo de saída** não deve ter uma senha.
* O **modelo de banco de dados** provavelmente precisaria ter uma senha criptografada.

/// danger

Nunca armazene senhas em texto simples dos usuários. Sempre armazene uma "hash segura" que você pode verificar depois.

* Certifique-se de ter modelos Pydantic bem definidos para seus corpos de solicitação e respostas.
* Configure quaisquer permissões e funções necessárias usando dependências.
* Nunca armazene senhas em texto simples, apenas hashes de senha.
* Implemente e use ferramentas criptográficas bem conhecidas, como tokens JWT e Passlib, etc.
* Adicione controles de permissão mais granulares com escopos OAuth2 quando necessário.
* ...etc.

Mas primeiro, vamos verificar alguns pequenos conceitos.

## Está com pressa?

Se você não se importa com qualquer um desses termos e só precisa adicionar segurança com autenticação baseada em usuário e senha _agora_, pule para os próximos capítulos.

## OAuth2

OAuth2 é uma especificação que define várias formas para lidar com autenticação e autorização.