US1.3

Autenticação de Usuários (RF03)

História de Usuário

Como usuário (estudante, organização ou administrador), quero fazer login na plataforma de forma segura para acessar funcionalidades específicas do meu perfil.

Rastreabilidade

Item	Código / Referência
User Story	US1.3
Requisito Funcional	RF03 — Autenticar usuário: Garantir o acesso seguro à plataforma via login e senha.
Característica de Produto	CP01 — Gestão de Usuários e Entidades
Requisitos Não-Funcionais	RNF01 (Criptografia de senhas), RNF02 (Tempo de resposta ≤ 2s)
Release Planejada	R1 — Fundação (26/05/2026)

Descrição

O Liaison é uma plataforma com três perfis distintos: estudantes, organizações sociais e administradores (Sysmin). Cada perfil possui funcionalidades exclusivas e dados sensíveis. Para garantir segurança e personalização da experiência, é necessário um mecanismo de autenticação robusto que valide credenciais (e-mail e senha) e redirecione o usuário para o fluxo correto conforme seu perfil. O sistema deve ser resiliente a tentativas de acesso indevido, não revelando qual campo está incorreto em caso de falha, e deve responder rapidamente (≤ 2s) para não comprometer a experiência mobile-first.

Alcance: Full-stack — formulário de login no frontend (React Native/Expo), API de autenticação no backend (Django REST Framework + JWT), e validação de credenciais criptografadas no banco (PostgreSQL).

Critérios de Aceite (BDD / Gherkin)

Dado que o usuário possui uma conta ativa com e-mail e senha cadastrados Quando ele preenche o formulário de login com credenciais válidas e submete Então o sistema autentica o usuário e o redireciona para a tela inicial correspondente ao seu perfil (estudante, organização ou administrador)

Cenário 2: Falha de autenticação com mensagem genérica

Dado que o usuário está na tela de login Quando ele insere um e-mail ou senha incorretos e submete Então o sistema exibe a mensagem genérica "E-mail ou senha inválidos" sem indicar qual campo está incorreto, e não concede acesso

Cenário 3: Tentativa de acesso com conta inativa

Dado que existe uma conta cadastrada cujo acesso não está liberado (ex.: organização aguardando moderação) Quando o usuário tenta autenticar-se com as credenciais dessa conta Então o sistema informa que a conta não está ativa, sem detalhar o motivo

Cenário 4: Tempo de resposta dentro do limite aceitável

Dado que o servidor está em condições normais de rede e carga Quando o usuário submete o formulário de login Então o sistema responde em no máximo 2 segundos (RNF02)

Regra DoR-G02: Todo item de backlog deve conter pelo menos um cenário de aceitação estruturado no formato Dado / Quando / Então.

Regras de Negócio

Acesso restrito a contas ativas: Somente usuários cuja conta esteja em situação regular e ativa podem autenticar-se na plataforma.
Autenticação por e-mail e senha: O acesso ao sistema é controlado exclusivamente por meio de e-mail e senha cadastrados.
Proteção contra enumeração de contas: Em caso de falha na autenticação, o sistema não deve revelar se o e-mail informado está cadastrado ou se a senha está incorreta. A mensagem exibida deve ser genérica e idêntica em ambos os casos.
Redirecionamento por perfil: Após autenticação bem-sucedida, o usuário deve ser direcionado às funcionalidades correspondentes ao seu tipo de perfil — estudante, organização social ou administrador.
Conta inativa: Caso a conta exista mas não esteja liberada para acesso (ex.: cadastro de organização pendente de moderação), o sistema deve informar que o acesso não está disponível, sem expor o motivo específico da inativação.

Requisitos Técnicos

Backend: Endpoint POST /api/v1/auth/login/ utilizando TokenObtainPairView do djangorestframework-simplejwt com email como USERNAME_FIELD.
Backend: Serializer customizado para incluir o perfil do usuário (student/organization/admin) no payload do token JWT.
Backend: Renovação de sessão via refresh token com tempo de expiração superior ao token de acesso, dispensando nova digitação de credenciais.
Backend: Hashing de senha via django.contrib.auth com algoritmo irreversível (PBKDF2 + bcrypt), conforme RNF01.
Backend: Testes unitários e de integração com pytest, cobertura mínima de 80%.
Backend: Configuração global DEFAULT_PERMISSION_CLASSES = [IsAuthenticated]; endpoint de login com permissão explícita AllowAny.
Frontend: Tela de login em React Native + Expo, com campos controlados e validação de formato de e-mail antes do envio.
Frontend: Armazenamento seguro dos tokens de autenticação no dispositivo (ex.: expo-secure-store).
Frontend: Redirecionamento condicional após login baseado no perfil retornado pelo backend.

Referências de Design

Protótipo Figma (Desktop): https://www.figma.com/design/f6bQuVohTvZLF5WWPEbNob/Liaison?node-id=0-1&p=f&t=lTwljNNcyUQi1AQz-0
Protótipo Figma (Mobile): https://www.figma.com/design/f6bQuVohTvZLF5WWPEbNob/Liaison?node-id=0-1&p=f&t=lTwljNNcyUQi1AQz-0

Regra DoR-G06: Para tarefas que envolvem frontend, o link do protótipo (Figma) deve estar anexado à tarefa.

Dependências

Relacionada a: #12 (US1.1 / RF01 — Cadastro de Estudantes) — Necessário para dispor de credenciais de estudantes em testes de integração.
Relacionada a: #13 (US1.2 / RF02 — Cadastro de Organizações) — Necessário para dispor de credenciais de organizações em testes de integração.
Tipo de dependência: Soft (conforme backlog §10.2.3 — item #4, prof. 0). O endpoint de autenticação pode ser desenvolvido e testado com dados simulados (mocks/fixtures) em paralelo com #12 e #13. A integração completa depende dos cadastros.
Bloqueia: #18 (US1.7 / RF06 — Painel Administrativo Sysmin) — O acesso administrativo exige autenticação prévia.

Notas

Prioridade no backlog (§10.2.3): #4 Must Have, ICE=900 (I=10, C=10, E=9), Quick Win, prof. 0. Item fundacional — sem impedimentos para iniciar.
A configuração de email como USERNAME_FIELD exige que REQUIRED_FIELDS inclua username para que createsuperuser funcione corretamente (PROJECT_CONTEXT.md §10).
TokenObtainPairView do simplejwt utiliza email automaticamente quando USERNAME_FIELD = 'email' — não requer serializer customizado para o campo, apenas para inclusão do perfil no payload.
Em ambiente de desenvolvimento mobile, ALLOWED_HOSTS=* é aceitável somente com DEBUG=True.

Definição de Preparado (DoR)

Item de Verificação (Universal)	Evidência / Rastreabilidade	Situação
A história está bem descrita e com critérios de aceite?	Documentada e alinhada com o escopo do MVP.	✔ Sim
Possui protótipos de interface necessários?	Interface mapeada e disponível no Figma da equipe.	✔ Sim
A história é independente o suficiente para ser entregue?	Cadeia de dependências resolvida (vide Matriz MVP).	✔ Sim
Foi estimada pela equipe?	Estimada utilizando o método ICE Score.	✔ Sim

Definição de Pronto (DoD)

Pergunta Fundamental (Universal)	Evidência de Implementação	Status
O código foi implementado e revisado?	Pull Request aprovado e fundido na branch principal.	✔ Sim
Coerente com o protótipo validado?	O layout segue os componentes e tokens de design.	✔ Sim
Passou nos testes necessários?	Testes (unitários/integração) executados e aprovados.	✔ Sim
A documentação está atualizada?	Atualizada no repositório de requisitos.	✔ Sim

Critérios de Aceitação (CA)

Login com sucesso: O usuário informa e-mail e senha corretos e é redirecionado para a tela correta de acordo com seu tipo de conta (estudante vai para o feed de vagas, organização vai para o painel de vagas, administrador vai para o painel de moderação).
Credenciais erradas: Se o e-mail ou a senha estiverem incorretos, o sistema exibe a mensagem genérica "E-mail ou senha inválidos" — sem revelar qual dos dois está errado — e não permite o acesso.
Conta inativa: Se a conta existir, mas ainda não estiver liberada (ex.: organização aguardando moderação), o sistema informa que o acesso não está disponível, sem detalhar o motivo.
Resposta rápida: O login responde em até 2 segundos em condições normais de uso.

Acesso & Evidência

Código Homologado: Repositório Principal
Status de Conclusão: 100% Entregue (conforme Matriz de Completude).