Atualizar Auth

Rafael Alves Lopes 2026-05-27 16:41:38 -03:00
parent 619fb949a7
commit 5569c863bf

55
Auth.md

@ -22,6 +22,7 @@ src/modules/auth/
├── auth.service.ts # Fachada — delega para os providers ├── auth.service.ts # Fachada — delega para os providers
├── auth.config.ts # Leitura de variáveis de ambiente ├── auth.config.ts # Leitura de variáveis de ambiente
├── auth-token.service.ts # Emissão de JWT da aplicação ├── auth-token.service.ts # Emissão de JWT da aplicação
├── user-access.service.ts # Sincronização do usuário autenticado com o banco
├── auth.types.ts # Interfaces TypeScript compartilhadas ├── auth.types.ts # Interfaces TypeScript compartilhadas
└── providers/ └── providers/
├── ldap-auth.provider.ts # Autenticação LDAP/AD ├── ldap-auth.provider.ts # Autenticação LDAP/AD
@ -91,6 +92,9 @@ Frontend
→ Se o bind falhar: UnauthorizedException → Se o bind falhar: UnauthorizedException
→ Busca dados do usuário no diretório (se LDAP_SEARCH_BASE configurado) → Busca dados do usuário no diretório (se LDAP_SEARCH_BASE configurado)
→ Monta objeto AuthenticatedUser → Monta objeto AuthenticatedUser
→ UserAccessService.syncAuthenticatedUser()
→ Cria/atualiza usuarios e usuarios_provedores
→ Carrega perfis, areas e area principal
→ AuthTokenService.issueToken() → AuthTokenService.issueToken()
→ Gera JWT assinado com JWT_SECRET → Gera JWT assinado com JWT_SECRET
→ Retorna { token, user } para o frontend → Retorna { token, user } para o frontend
@ -113,6 +117,7 @@ O AD apenas valida a identidade. O JWT emitido é da aplicação, não do AD.
→ Backend valida o state (assinatura + expiração) → Backend valida o state (assinatura + expiração)
→ Backend troca o code por access_token (chamada server-to-server) → Backend troca o code por access_token (chamada server-to-server)
→ Backend consulta Microsoft Graph /me para obter dados do usuário → Backend consulta Microsoft Graph /me para obter dados do usuário
→ UserAccessService.syncAuthenticatedUser() sincroniza o usuário no banco
→ AuthTokenService.issueToken() gera JWT próprio → AuthTokenService.issueToken() gera JWT próprio
→ Backend redireciona para MICROSOFT_SUCCESS_REDIRECT_URL?token=... → Backend redireciona para MICROSOFT_SUCCESS_REDIRECT_URL?token=...
@ -148,15 +153,41 @@ Após qualquer autenticação bem-sucedida, o `AuthTokenService` emite um JWT co
```json ```json
{ {
"sub": "identificador-do-usuario", "sub": "4",
"name": "Nome Completo", "name": "Nome Completo",
"email": "usuario@empresa.com", "email": "usuario@empresa.com",
"provider": "ldap", "provider": "ldap",
"username": "usuario" "username": "usuario",
"perfis": ["Admin"],
"profiles": ["Admin"],
"areas": ["Suporte"],
"areaPrincipal": "Suporte",
"accessStatus": "assigned"
} }
``` ```
O `sub` é atualmente o email ou identificador externo. Quando houver banco de dados, deve ser substituído pelo ID interno da tabela `users`. O `sub` usa o ID interno da tabela `usuarios`, convertido para string. O mesmo ID também é retornado no objeto de usuário como `databaseId`.
O JWT é emitido e salvo no frontend, mas ainda falta a camada de `AuthGuard` no NestJS para validar o token nas rotas privadas. Portanto, hoje o token representa a sessão do usuário para o frontend, mas o backend ainda precisa ser endurecido para produção.
---
## Sincronização de usuário e acesso
Após o provedor autenticar o usuário, o `UserAccessService`:
1. faz upsert em `usuarios` usando email ou fallback `provider:username`;
2. faz upsert em `usuarios_provedores`;
3. consulta perfis em `usuarios_perfis` + `perfis_acesso`;
4. consulta especialidades em `usuarios_areas` + `areas`;
5. retorna o usuário enriquecido com:
- `databaseId`;
- `perfis` / `profiles`;
- `areas`;
- `areaPrincipal`;
- `accessStatus`.
`accessStatus` fica como `assigned` quando o usuário possui perfil e área. Usuários sem vínculo suficiente entram como `unassigned` e caem na tela de pendência no frontend.
--- ---
@ -251,10 +282,18 @@ loginComNovoProvedor(dados: any) {
## O que ainda falta para produção ## O que ainda falta para produção
- [ ] Tabela `users` no banco de dados - [x] Tabela `usuarios` no banco de dados
- [ ] Tabela `auth_identities` para vincular provedores externos ao usuário interno - [x] Tabela `usuarios_provedores` para vincular provedores externos ao usuário interno
- [ ] `sub` do JWT usando ID interno do banco, não email externo - [x] `sub` do JWT usando ID interno do banco
- [ ] Guard NestJS para proteger rotas privadas (`@UseGuards(AuthGuard)`) - [ ] Guard NestJS para proteger rotas privadas (`@UseGuards(AuthGuard)`)
- [ ] Roles e permissões - [ ] Roles e permissões validadas no backend
- [ ] Auditoria de login - [ ] Auditoria de login
- [ ] Trocar token na query string por cookie HTTP-only (reduz exposição no browser) - [ ] Trocar token na query string por cookie HTTP-only (reduz exposição no browser)
---
## Documentacao complementar
A sincronizacao de usuarios autenticados com o banco, os perfis de acesso, as areas operacionais e os endpoints administrativos estao documentados em:
- [`access-control.md`](./access-control.md)